| xnox | highvoltage: =)))) it was magic to me, when "accelerated" dlocate was pointed out to me. | 01:55 |
|---|---|---|
| === freeflying is now known as freeflying_away | ||
| infinity | siretart: I noticed, yep. handbrake finally built after being in proposed for two cycles. :P | 03:39 |
| infinity | siretart: I guess as soon as the libtiff5 transition happens in Debian, we can just sync? That'll be pleasant. | 03:48 |
| infinity | siretart: Should make security much simpler too, assuming you're already doing decent security support for libav in Debian. | 03:48 |
| infinity | (And maybe no one is... Hrm...) | 03:49 |
| === freeflying_away is now known as freeflying | ||
| pitti | Good morning | 05:23 |
| infinity | jamesh: Where did your openvswitch "2.0.0" come from? All I can find tagged upstream is 1.9.3 | 05:47 |
| infinity | jamesh: Also, still not ported to 3.12. Boo. | 05:47 |
| infinity | jamesh: Err, james tab fail. | 05:47 |
| infinity | jamespage: ^^^ | 05:47 |
| pitti | http://openvswitch.org/releases/openvswitch-2.0.0.tar.gz ? | 05:48 |
| pitti | (that's what Debian PTS says, with the watchfile) | 05:48 |
| infinity | pitti: Cute, given that it's not tagged in git. | 05:48 |
| infinity | Looks like maybe they just forgot to tag it, I see the "prepare" commit. | 05:49 |
| infinity | jamespage: Nevermind on the first question, looks like they just forgot to tag it. | 05:50 |
| infinity | jamespage: The "not ported to 3.12" thing's still irksome, though. I now have autopkgtest yelling at me. :P | 05:51 |
| pitti | perhaps we could add a linux-libc-dev build depend to openvswitch, so that in the future openvswitch's autopkgtest runs with a kernel update | 05:53 |
| pitti | then the kernel would be held back until openvswitch is fixed, instead of silently breaking it | 05:53 |
| infinity | pitti: Hrm? | 05:53 |
| infinity | pitti: It's not linux-libc-dev, it's linux-headers (it's a dkms module that explodes), but yeah, ISWYM. | 05:54 |
| pitti | infinity: ah, or make openvswitch-datapath-dkms depend on some linux-y package, sure | 05:55 |
| pitti | not sure whether we would actually want to block the kernel for these, but in principle it's "new linux breaks existing stuff" | 05:55 |
| infinity | pitti: Well. It shouldn't. That's a bit of a problem. Adding arbitrary incorrect dependencies to trick adt seems a bad idea. | 05:55 |
| pitti | infinity: not really -- openvswitch-datapath-dkms does need the kernel headers and doesn't depend on them | 05:56 |
| infinity | pitti: No, no, no, no. And no. | 05:56 |
| pitti | we just mostly don't add them because we don't know *which* kernel headers to depend on | 05:56 |
| pitti | it's a kind of "implicit", "you need some of them" dependency | 05:56 |
| infinity | pitti: I've faught hard to get people to STOP adding linux-headers-foo deps to packages, because they're never correct, and can't be. | 05:56 |
| pitti | which we can't express | 05:56 |
| pitti | infinity: yes, I'm aware of that | 05:56 |
| infinity | pitti: No different from packages that depend on a linux kernel version, we can't express that either. | 05:57 |
| pitti | infinity: hence my proposal to add linux-libc-dev instead, which is also built by the kernel | 05:57 |
| pitti | while any fixed package name as a dep is wrong, not having any dependency at all is also wrong | 05:57 |
| pitti | it's just more conveniently wrong :) | 05:57 |
| pitti | but stops us from being able to detect those regressions in -proposed | 05:58 |
| infinity | I suppose it ends up pulling in linux-libc-dev anyway, since it depends on libc6-dev, so it's not going to add more useless croft. | 05:58 |
| infinity | Nor cruft... | 05:59 |
| pitti | yes, it's build-essential | 05:59 |
| infinity | But perhaps we should rather special-case dkms rdeps to recurse for kernel testing. | 05:59 |
| infinity | Adding debian/control curft to every dkms package seems inelegant. | 06:00 |
| infinity | WHY CAN'T I TYPE THE WORD CRUFT?! | 06:00 |
| pitti | (you just did) | 06:00 |
| infinity | Yeah, yeah. :P | 06:00 |
| infinity | croft... curft... I'm on a roll. | 06:00 |
| pitti | but yes, it affects many other packages, too | 06:00 |
| pitti | infinity: we have a whole set of jenkins jobs for dkms, FYI (https://jenkins.qa.ubuntu.com/view/DKMS/) | 06:01 |
| infinity | pitti: Yeah, I know, but those don't block kernel migration, clearly. | 06:01 |
| infinity | Or proposed migration in general. | 06:01 |
| pitti | right | 06:01 |
| pitti | jibel and the kernel team discussed that at length, not sure whether not blocking in -proposed on DKMS regressions was intended or not | 06:02 |
| pitti | (as we clearly don't want to block it for *every* DKMS package we have in the archive) | 06:02 |
| infinity | Sure we do. | 06:02 |
| infinity | Just as we block on any other regression. So we can examine the situation and take a decision. | 06:02 |
| infinity | The kernel isn't any more a unique snowflake than any other package in that regard. | 06:03 |
| pitti | I guess their concern was that we don't really support most DKMS packages that we import from Debian, and if we'd do that blocking we essentially would have to | 06:04 |
| infinity | See, the way I see it, we have to either fix, remove, or temporarily ignore every failure. But it's better to know than not. | 06:04 |
| infinity | Just like any other transition. | 06:04 |
| pitti | we certainly don't want to break the nvidia/fglrx/bcmwl drivers with new kernels, though | 06:04 |
| infinity | A, B, and C get fixed, D gets removed because we don't care. | 06:05 |
| infinity | Leaving D broken is bad. Not fixing C when we could have with a trivial patch is also bad. | 06:05 |
| pitti | I'd be happy with that; I was just saying what they discussed back then | 06:05 |
| infinity | I think the story is different for lts-hwe stuff, where a dkms package might work with 3.2 but not 3.8, and we might opt to just leave the 3.8 path broken. | 06:06 |
| infinity | But no such excuse in a devel series with only one kernel. | 06:06 |
| infinity | Anyhow, I don't remember ever discussing tying this into britney when we talked about dkms automagic testing, so I don't think there's some process failure here, just something we never got around to discussing and implementing. :) | 06:08 |
| jibel | we never discussed about blocking automatically the kernel when there is a failure with a dkms module. Currently kernel n+1 from the kernel team ppa is tested and manually reviewed, and published to the distro after review by the kernel team. | 06:11 |
| infinity | jibel: Sure, I know, I'm a big part of the SRU process, and that's all basically fine, IMO, but I think the devel process might need some work here. | 06:12 |
| infinity | jibel: Not anything newly broken that wasn't before, so no big rush to sort out something better, but I think we should think about it. | 06:13 |
| * infinity glares at libticables' configure.ac and wishes for laser vision. | 06:15 | |
| * xnox thought at one point we wanted to block kernel on some _important_ dkms modules, but not all of them. | 06:17 | |
| jamespage | infinity, I failed to find time for the powerpc build failure as well | 06:18 |
| jamespage | infinity, and yes it does not support 3.12 | 06:18 |
| infinity | jamespage: I fixed the PPC failure, which is why I'm now being yelled at by autopktest about 3.12 incompat. ;) | 06:18 |
| jamespage | infinity, but we may actually be able to drop the dkms packages as the kernel natively supports GRE and VXLAN tunnels | 06:18 |
| jamespage | infinity, but I still need to check that out... | 06:18 |
| infinity | jamespage: Oh, if the dkms package can disappear, that would be lovely. | 06:18 |
| jamespage | infinity, agreed - I'm really looking forward to not having to fix it with every kernel bump we do | 06:19 |
| jamespage | I had to cherry pick the 3.11 support from trunk | 06:19 |
| infinity | jamespage: Yeahp, and by the time 3.12 is fixed, we'll be on 3.13. ;) | 06:20 |
| infinity | (Not to mention lts-backport kernels in 14.04...) | 06:20 |
| jamespage | infinity, I just need to check with upstream with some of the megaflows stuff - I don't understand whether thats in the upstream native kernel module or not | 06:20 |
| jamespage | and will be important to some larger cloud users | 06:20 |
| jamespage | infinity, time is my problem this week | 06:20 |
| infinity | jamespage: I'm happy to leave it in its current state in proposed, if you're chasing down the dkms things. I was just whining because of the angry email I got after fixing it. :) | 06:25 |
| jamespage | infinity, OK - leave it with me - I'll check this next week | 06:25 |
| jibel | pitti, I proposed a patch for sbuild and pbuilder autopkgtest failures. If you have a minute for a review it is bug 1247420 | 06:34 |
| ubottu | bug 1247420 in sbuild (Ubuntu) "autopkgtest failure: build deps of procenv cannot be satisfied because expat is in universe and universe is not enabled" [High,Triaged] https://launchpad.net/bugs/1247420 | 06:34 |
| pitti | jibel: oh, do we limit autopkgtest dependencies to main now for main packages? | 06:42 |
| jibel | pitti, no it is in the test, the chroot used to test pbuilder and sbuild only have main enabled | 06:43 |
| infinity | Yeah, it's creating a chroot in the test, which makes sense, given the package being tested. | 06:43 |
| infinity | jibel: So, I'm all for the other improvements to those tests (fixing set -e, using better lsb_release bits), but would have been nice to have them in another commit, so you could more easily split out the bunch and submit them to Debian as two different patches. | 06:46 |
| pitti | jibel: or it could perhaps build a package in main? | 06:46 |
| pitti | infinity: the autopkgtest of at least sbuild isn't in Debian at all, FYI | 06:46 |
| infinity | Oh, it's not? Figured it was, given the lsb_release forking based on release. | 06:46 |
| infinity | Nevermind, then. :) | 06:46 |
| pitti | jibel: ah, nevermind; with that it can test the "components=" functionality, too :) | 06:47 |
| * infinity does appreciate it when a test tests as much as it can. | 06:47 | |
| infinity | Unit testing is for wimps. | 06:47 |
| * infinity is quite fond of rbasak's libapache2-mod-svn test that appears to test svnadmin, svn, and the apache module, all in one go. | 06:49 | |
| infinity | Which is, basically, the entire source package. | 06:49 |
| pitti | i. e. "fastest" and "hardest to debug" :) | 06:49 |
| pitti | but as long as these tests give you useful output when they fail, it seems okay | 06:49 |
| infinity | pitti: Well, when your testsuite is essentially a shell script, it's not hard to debug where one line breaks. | 06:50 |
| infinity | (Obviously, unit testing and the like have their place when your tests need to be more complex, or you're testing for specific regressions, etc, but most autopkgtests don't seem that fancy) | 06:51 |
| infinity | I do question if maybe some of them SHOULD be that fancy. | 06:51 |
| pitti | jibel: can you please forward the updated test to debian bug 705926 ? | 06:51 |
| ubottu | Debian bug 705926 in sbuild "sbuild: Add basic DEP-8 autopkgtest" [Normal,Open] http://bugs.debian.org/705926 | 06:51 |
| infinity | When I was working on Maemo, we were religiously breaking build-time test suites out into -tests runtime packages and mangling them to run under a runtime test harness. | 06:51 |
| infinity | Which, obviously, took way longer to run than the average autopkgtest, but also provided some decent coverage in some cases. | 06:52 |
| infinity | Undecided if the pain was worth it. | 06:52 |
| jibel | pitti, sure, and pbuilder diff to 705917 | 06:53 |
| pitti | jibel: en effet, merci ! | 06:53 |
| === iahmad is now known as iahmad|afk | ||
| === mnepton is now known as mneptok | ||
| sil2100 | stgraber: ping! | 08:41 |
| pitti | tseliot: hm, nvidia and fglrx build, but nvidia-updates and fglrx-updates fail: http://paste.ubuntu.com/6357855/ | 09:29 |
| pitti | tseliot: (detected by ubuntu-drivers-common autopkgtest) | 09:29 |
| pitti | tseliot: want a bug for that, or are you on it? I suppose the non-updates variants have a patch which isn't applied to -updates? | 09:30 |
| tseliot | pitti: I'm wondering why the system we have in place doesn't send me an email as planned | 09:30 |
| pitti | tseliot: that's | 09:30 |
| pitti | err | 09:30 |
| pitti | tseliot: that's mostly because the autopkgtest isn't in the nvidia/fglrx package itself, but in u-d-common; that didn't get an upload | 09:30 |
| pitti | tseliot: so the system doesn't know whom to contact, it just contacts jibel and me as fallback | 09:31 |
| tseliot | pitti: oh, ok. Please add my email address when you can. I'll check all the flavours, just to be sure | 09:32 |
| pitti | tseliot: the other flavours are fine; the current u-d-c test on jenkins fails all of them due to something else, but I just fixed that in git (uploading now) | 09:32 |
| pitti | well, we test nvidia 304 and 319 and fglrx, and all -upates for those, perhaps there are other flavours by now | 09:33 |
| tseliot | pitti: there's 173. Also I'm going to introduce 331 | 09:34 |
| pitti | tseliot: thanks; I'm uploading u-d-common now as the other tests are fixed again | 09:35 |
| tseliot | pitti: ok, thanks | 09:36 |
| didrocks | pitti: hey! | 10:11 |
| seb128 | is anyone here on saucy with some hardware which requires binary drivers (e.g use of the software-properties' driver install) | 10:12 |
| seb128 | I need somebody to SRU confirm bug #1241210 | 10:12 |
| ubottu | bug 1241210 in software-properties (Ubuntu Saucy) "shouldn't use deprecated gtk-logout-helper" [High,Fix committed] https://launchpad.net/bugs/1241210 | 10:12 |
| didrocks | pitti: IIRC, you were the one adding me to ubuntu-drivers. I think I'm going to expire from the team. I think it would make more sense that I'm part of this team through UDS organizer, being a track lead? | 10:14 |
| didrocks | pitti: it seems only the tech board (but only having sabdfl in this team?) is an admin for it | 10:14 |
| seb128 | didrocks, TB expired and need to be renewed I think, until then you might need sabdfl/get stucked :/ | 10:17 |
| didrocks | yeah, let's see how it goes… | 10:17 |
| didrocks | I guess the issue of TB expiring impacted many other nominations | 10:18 |
| pitti | didrocks: -ENOTECHBOARD at the moment, I'm afraid :/ | 10:18 |
| didrocks | yeah | 10:18 |
| pitti | seb128: /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk ? | 10:18 |
| seb128 | pitti, thanks, I didn't know about /usr/share/ubuntu-drivers-common/fake-devices-wrapper | 10:21 |
| pitti | seb128: heh, I cobbled that together back then for that very reason (it's been a while since I actually had a computer which needs binary drivers) | 10:23 |
| seb128 | pitti, is it actually downloading/installed drivers when you use the UI? (it seems to be really downloading stuff, I wonder if I'm going to end up with nvidia installed :p) | 10:24 |
| seb128 | it does it seems | 10:24 |
| pitti | seb128: yes, you will | 10:25 |
| pitti | so better uninstall it again afterwards, unless that's a VM | 10:25 |
| seb128 | pitti, thanks | 10:25 |
| seb128 | (hum, it doesn't prompt me for reboot :/) | 10:25 |
| pitti | seb128: in the original designs it was supposed to update the status to something like that after installation ("restart computer to activate" or so) | 10:26 |
| seb128 | pitti, well, I'm trying to test https://code.launchpad.net/~seb128/software-properties/dont-use-deprecated-reboot-commands/+merge/191720 | 10:27 |
| * seb128 reads code again | 10:27 | |
| seb128 | good, that's working | 10:30 |
| seb128 | pitti, danke | 10:30 |
| pitti | seb128: ah, good; seems a bit confusing to invoke that dialog, but I guess better than no confirmation at all | 10:32 |
| seb128 | pitti, right, better than getting a whoopsie dialog because the code is calling a non existing binary, in any case | 10:33 |
| pitti | heh, absolutely :) | 10:33 |
| === tkamppeter__ is now known as tkamppeter | ||
| === _salem is now known as salem_ | ||
| === slomo__ is now known as slomo | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === Ursinha_ is now known as Ursinha | ||
| hrw | hi | 12:49 |
| === MacSlow|lunch is now known as MacSlow | ||
| === gusch is now known as gusch|away | ||
| brainwash | pitti: hey, could the logind resume issue be indeed related to some bug in kernel 3.11? the new systemd-shim package only fixed the problem for like 50% of the people | 13:51 |
| pitti | brainwash: or it could be that they suspended for more than 10 minutes? | 13:52 |
| pitti | brainwash: if that's not it, then I suppose there's another, independent, bug somewhere between logind and shim | 13:52 |
| brainwash | pitti: https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262/comments/103 | 13:53 |
| ubottu | Ubuntu bug 1184262 in systemd-shim (Ubuntu Trusty) "[logind] times out too early, stuck in PrepareForSleep, causing network and other services to not resume" [High,In progress] | 13:53 |
| brainwash | maybe the 30sec d-bus timeout? | 13:53 |
| brainwash | i can only reproduce it with a fake suspend | 13:54 |
| brainwash | but it would explain why logind does not get stuck for some people, it simply reverts back to PrepareForSleep = false after the d-bus timeout | 13:55 |
| brainwash | hopefully some people will post their log files | 13:56 |
| === freeflying is now known as freeflying_away | ||
| maxiaojun | https://bugs.launchpad.net/ubuntu/+source/rar/+bug/776851 | 14:26 |
| ubottu | Ubuntu bug 776851 in rar (Ubuntu) "Please backport rar 2:4.2.0-0ubuntu1 from raring" [Undecided,Confirmed] | 14:26 |
| maxiaojun | can anyone help this? | 14:26 |
| xnox | maxiaojun: why bug against ubuntu-package? backports are tracked / managed by backports projects only. | 14:30 |
| maxiaojun | the bug wasn't a back port request | 14:31 |
| xnox | maxiaojun: it had tasks open against Backports project so yes, it was a backport request. Was it meant to be something else? | 14:32 |
| xnox | maxiaojun: and it's fix-released in 13.04 and up. | 14:33 |
| maxiaojun | xnox: fixed in short term releases isn't that useful | 14:33 |
| maxiaojun | xnox: it was a bug towards rar package only | 14:33 |
| xnox | maxiaojun: in that case, you should have nominated the bug for series where it's still a problem and follow the StableReleaseUpdates procedure. Do you know about Stable Release Updates? | 14:35 |
| maxiaojun | i should have asked and may be someone told me that the best i can get is back port | 14:37 |
| xnox | maxiaojun: #ubuntu-bugs are usually helpful when "i know where/what needs to be fixed, but not sure how to properly triage/request that" | 14:38 |
| xnox | maxiaojun: load up bug #776851 again | 14:38 |
| ubottu | bug 776851 in rar (Ubuntu Quantal) "Please backport rar 2:4.2.0-0ubuntu1 from raring" [Undecided,Incomplete] https://launchpad.net/bugs/776851 | 14:38 |
| xnox | maxiaojun: I've nominated it for Precise & Quantal with status incomplete, and set it to fix released (aka raring and up are fine) | 14:39 |
| xnox | maxiaojun: I've also added a comment about stable release updates. | 14:39 |
| xnox | maxiaojun: if you can provide information as per template "https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template" that would be a great help. | 14:39 |
| maxiaojun | the problem is very very clear | 14:39 |
| xnox | focus on test-cases and regression testing, e.g. sample test files that used to fail and now pass, and regular files that worked before and not after. | 14:40 |
| xnox | maxiaojun: it is not to me. It should be made clear to those who don't use that package, developers and "Ubuntu Stable Release Team" who ultimately decide if an update goes in. | 14:41 |
| xnox | maxiaojun: by default we do not update package in stable releases, and only release targetted bugfixes. | 14:41 |
| maxiaojun | haven't you seen all the previous user comments? | 14:41 |
| xnox | maxiaojun: sure, but somebody neeeds to summarise what a problem is, steps to re-create reproduce, and assess regression potential. | 14:42 |
| maxiaojun | *any* rar file with non-ascii filenames in it is a test case | 14:42 |
| xnox | maxiaojun: well then write that up. using https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template | 14:43 |
| maxiaojun | yes, rar 4.20 is very likely to break rar 4.0 beta 3 | 14:43 |
| maxiaojun | because old bugs cannot be reproduced | 14:43 |
| xnox | maxiaojun: without those steps done, it will not be uploaded / accepted into stable updates channels for precise/raring. | 14:43 |
| xnox | maxiaojun: did command line options changes? are all/same binaries present? did it gain extra dependencies? or loose some? | 14:44 |
| maxiaojun | none | 14:44 |
| xnox | maxiaojun: if you don't want to work on getting a Stable Release Update out for rar, that's ok. But _I'm_ not going to do it. Hopefully somebody else well. | 14:45 |
| xnox | s/well/will. | 14:45 |
| maxiaojun | i appreciate your wild imagination | 14:45 |
| maxiaojun | https://bugs.launchpad.net/ubuntu/+source/rar/+bug/731066 | 14:47 |
| ubottu | Ubuntu bug 731066 in rar (Ubuntu) "[needs packaging] New upstream stable release available: RAR 4.20" [Wishlist,Fix released] | 14:47 |
| maxiaojun | asked about SRU before | 14:47 |
| maxiaojun | but as bugs being marked "fixed", it is a bit hard to find them out | 14:47 |
| xnox | maxiaojun: now it's on https://bugs.launchpad.net/ubuntu/quantal and https://bugs.launchpad.net/ubuntu/precise pages | 14:49 |
| xnox | maxiaojun: bug needs to be nominated to the series where it's still a bug, if it's significant enough to warrant an SRU, and if someone is working on getting it out. | 14:50 |
| maxiaojun | but a normal use cannot request for nomination | 14:50 |
| maxiaojun | during the raring cycle the culture was a bit different, as 9-month-support (useless support) isn't decided yet | 14:52 |
| maxiaojun | xnox: do you think i should still try sru request? | 14:54 |
| xnox | maxiaojun: i believe anyone can request to nominate. and then it will be pending to be "accept/decline" nomination. which developers regularly go through. | 14:54 |
| maxiaojun | xnox: not the case | 14:54 |
| xnox | maxiaojun: or ping people on #Ubuntu-bugs to get bugs nominated. | 14:54 |
| maxiaojun | that's time-consuming | 14:55 |
| xnox | maxiaojun: i filed the sru request for you, based on your request. (nominated bug for the right series) | 14:55 |
| maxiaojun | thank you! where? | 14:55 |
| xnox | maxiaojun: if you fill out the template, then it will move to confirmed state. After that and update needs to be prepared (should be easy, since it's basically package version tweak) and then a sponsor will need to upload it. | 14:56 |
| xnox | maxiaojun: bug, same one. I've updated it to be nominated for series. <xnox> maxiaojun: load up bug #776851 again | 14:56 |
| ubottu | bug 776851 in rar (Ubuntu Quantal) "Please backport rar 2:4.2.0-0ubuntu1 from raring" [Undecided,Incomplete] https://launchpad.net/bugs/776851 | 14:56 |
| xnox | clcik on it. | 14:56 |
| maxiaojun | done | 15:16 |
| pitti | tseliot: FYI, https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/9/ARCH=amd64,label=adt/ is a current run, and has .crash files for the DKMS failures, and the logs (which now succeed for all packages except said two) | 15:40 |
| tseliot | pitti: thanks. I have fixed nvidia locally and now I'm working on the other package | 15:41 |
| pitti | tseliot: sweet, thanks | 15:41 |
| psusi | does anyone know what happened to the /etc/mtab -> /proc/mounts transition? I thoguht we supposedly had done that for new installs a release or two back, but it doesn't seem to be the case. What component is responsible for creating /etc/mtab ( dpkg says not owned by anyone )? Is it d-i? ubiquity? | 15:48 |
| === Ursinha is now known as Ursinha-afk | ||
| maxiaojun | xnox: don't how to do the version change in debdiff, and debdiff seems a little useless here as some files are binary only | 16:15 |
| xnox | maxiaojun: debdiff against raring package.... it will have correct version for the SRU, target release, changelog entry with bug closure (LP: #NNNYNNN) | 16:16 |
| xnox | something that a sponsor can apply against raring package, such that it's appropriately ready to be uploaded into "precise" and "quantal" series. | 16:17 |
| maxiaojun | "it will have" means i don't need to do anything special? | 16:18 |
| maxiaojun | as this package packages binary-only software, debdiff just captures some doc change actually | 16:19 |
| xnox | yes. it's packaging metadata change. | 16:19 |
| xnox | (the debian/changelog needs updating) | 16:19 |
| xnox | $ pull-lp-source rar raring | 16:19 |
| xnox | $ cd rar-* | 16:19 |
| xnox | $ dch -i | 16:19 |
| xnox | and then correct the entry: 1) target series 2) version number 3) entry text 4) bug number closure. | 16:20 |
| xnox | build the source package with $ debuild -S | 16:20 |
| xnox | and do a debdiff between raring version and the new one with $ debdiff | 16:20 |
| xnox | rince, repeat twice - once for precise and once for quantal. | 16:20 |
| === Ursinha-afk is now known as Ursinha | ||
| chiluk | so I'm trying to sru a fix for bip in precise, and it's currently versioned 0.8.8-1build1 what is the correct way to increment that build number? | 16:22 |
| xnox | chiluk: 0.8.8-1build1.1 or 0.8.8-1ubuntu0.1 | 16:25 |
| xnox | chiluk: note that u > b =) | 16:25 |
| chiluk | yeah... | 16:26 |
| * xnox preffers 0.8.8-1ubuntu0.1, but either is valid | 16:26 | |
| xnox | chiluk: the only hard-rule is that it needs to be >> then precise but << than quantal (or any possible SRUs / Security versions there) | 16:26 |
| xnox | s/then/than/ | 16:26 |
| xnox | and there in infinite amount of versions between 0.8.8-1build1 and 0.8.8-2 =) | 16:27 |
| xnox | chiluk: for luci-updates they used 0.8.2-1squeeze4build0.10.04.1 | 16:28 |
| xnox | which looks a bit odd =) but well, it works. | 16:28 |
| chiluk | xnox well in this case I'm backporting the only change from quantal back into precise. | 16:30 |
| maxiaojun | xnox: debdiff done, are they what you expected to see? | 16:35 |
| xnox | maxiaojun: yes, looks good. Subscribing ubuntu-sponsors. | 16:37 |
| xnox | maxiaojun: a few request piled up in the sponsoring queue at the moment. http://reqorts.qa.ubuntu.com/reports/sponsoring/ but very soon one of the patch pilots will review your debdiffs and/or comment with reviews or uploads it for Ubuntu Stable Release team to review. | 16:39 |
| xnox | maxiaojun: thanks a lot for your work! =) everything is done now, just wait for a sponsoring | 16:39 |
| xnox | your bug will appear on the report, next time it refreshes. | 16:39 |
| maxiaojun | thank you for your helps also! | 16:40 |
| xnox | maxiaojun: no problem =) | 16:44 |
| mapreri | Do you now if someone (doko?) will take care if pushing automake 1.14 in trusty? (ref: http://packages.qa.debian.org/a/automake-1.14.html and bug # 1191959) | 16:46 |
| mapreri | of* | 16:46 |
| xnox | mapreri: i'm working on it. but got sidetracked. | 17:00 |
| xnox | mapreri: i am aware of that bug and fix/patch. | 17:01 |
| xnox | mapreri: i still need to run full autopackage test. | 17:01 |
| xnox | I will send an email about it to ubuntu-devel and I hope to get automake 1.14 in, before the first full-archive trusty rebuild. | 17:01 |
| mapreri | xnox: great! I'm waiting for it :). Yesterday I was working on merging lighttpd, and it complains about the lack of automake 1.14, and I don't want at all to patch it to work with 1.13 :p | 17:05 |
| xnox | mapreri: just wait, or upload it with "Build-depends: automake (>= 1.14)" or whatever the proper epoch:version is. It will go into dep-wait state and will be built once the new automake is in. | 17:06 |
| cjwatson | It's also not terrible to just let it FTBFS until automake 1.14 is in | 17:10 |
| mapreri | xnox: cjohnston I prefer waiting... I definitely prefer performing a local build before uploading something | 17:11 |
| === bfiller is now known as bfiller_afk | ||
| === tvoss is now known as tvoss|dinner | ||
| slangasek | cjohnston: do we have an autoscheduler for this vUDS? | 17:59 |
| cjohnston | slangasek: nope | 17:59 |
| cjohnston | well, shouldnt | 17:59 |
| cjohnston | doesn't appear as though we do | 18:00 |
| cjwatson | FYI: publisher down pending investigation of I/O errors | 18:01 |
| slangasek | cjohnston: what do you mean, "shouldn't"? So the track leads need to schedule everything by hand | 18:02 |
| slangasek | ? | 18:02 |
| cjohnston | slangasek: correct... no auto scheduler... leads need to manually schedule things | 18:02 |
| slangasek | cjohnston: and who decided that this was a good idea? | 18:04 |
| cjohnston | slangasek: this was based on complaints from track leads | 18:04 |
| cjohnston | been this way for atleast all of the vUDS events IIRC | 18:04 |
| slangasek | cjohnston: ok, but who made this decision? I am a track lead, and have *never* complained about the presence of the autoscheduler. I also haven't been manually scheduling sessions for vUDS, which means someone else must have been doing it for the foundations track | 18:14 |
| slangasek | so if someone else is going to manually schedule the sessions, then I suppose I don't need to worry about it; but so far no one has done this for our blueprints this round | 18:15 |
| slangasek | and if no one else is doing this, then I will complain - loudly - about the busywork involved in manually scheduling these sessions | 18:15 |
| cjohnston | mhall119: do you have any more backstory on ^ | 18:16 |
| mhall119 | I don't know who made the original decision not to use autoscheduling, bit cjohnston is correct that it was never used for vUDS | 18:17 |
| mhall119 | I think, because track leads have to start every session's Hangout, we wanted to make sure they were scheduled according to the track lead's needs | 18:18 |
| knocte | hallo, how many Approve votes must a merge-request receive to be merged? | 18:26 |
| infinity | knocte: It's not about voting, it's about someone who can actually merge it being the approver. | 18:27 |
| infinity | (Can, and is willing to) | 18:27 |
| infinity | @pilot in | 18:28 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 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 -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity | ||
| infinity | knocte: Which MP is this? | 18:28 |
| knocte | infinity: https://code.launchpad.net/~knocte/ubuntu-themes/cleanup-empty-rules/+merge/192903 | 18:28 |
| infinity | Ahh, I won't touch that with a 20-foot pole, my knowledge of GTK themes isn't deep enough, but I'll see if it can get reviewed by someone who can merge it. | 18:32 |
| knocte | infinity: it doesn't require gtk superpowers really, just CSS knowledge to know that the patch brings sanity :) | 18:33 |
| knocte | s/CSS/basic CSS/ | 18:33 |
| infinity | knocte: Well, see. I know CSS well enough from, like, 1999, but I don't know if GTK's CSS relies on empty classes to work around quirks, or if the ubuntu themes themselves might, or whatever. So, I'd rather have someone more knowledgable sort it out and commit to the upstream branch. I've pinged someone to that end. | 18:35 |
| knocte | infinity: ok thanks; and to the best of my knowledge, gtk's CSS works (or should work, if it doesn't "file a bug") in the same way as normal CSS so I don't think there would be quirks or similar hacks | 18:36 |
| === bfiller_afk is now known as bfiller | ||
| hallyn_ | tjaalton: hey - so looking at https://launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/0.1.1-0ubuntu1 - do you think it's worth just trying rebuilds? | 19:39 |
| hallyn_ | it looks like libxext-dev didn't get installed | 19:40 |
| hallyn_ | I can dig, but don't know the dependencies in the X cruft very well | 19:41 |
| hallyn_ | hm, looks like xserver-xorg-video-qxl should perhaps be build-depping on it | 19:51 |
| mdeslaur | xnox: looks like you dropped some changes in thin-client-config-agent that caused LP: #1187450 | 19:52 |
| ubottu | Launchpad bug 1187450 in thin-client-config-agent (Ubuntu) "Depends on python3-pycurl" [Undecided,Confirmed] https://launchpad.net/bugs/1187450 | 19:52 |
| stgraber | utlemming: upload rights granted, you're all set | 19:54 |
| utlemming | stgraber: awesome, thank you sir | 19:54 |
| xnox | mdeslaur: =/ | 19:55 |
| xnox | mdeslaur: assigned to myself & scheduled SRUs. | 19:56 |
| mdeslaur | xnox: not sure if it's worth sruing, honestly | 19:56 |
| xnox | mdeslaur: well if remote login is broke, that's kind of important =/ | 19:57 |
| mdeslaur | xnox: ok | 19:58 |
| mdeslaur | xnox: thanks | 19:58 |
| infinity | hallyn_: You have any qemu days coming up in your schedule? | 20:06 |
| infinity | hallyn_: https://wiki.debian.org/Arm64Qemu <-- Do want in Ubuntu. And vagrant and co would happily take a sane patch for it in Debian too, from what he told me in #debian-arm | 20:07 |
| psusi | cjwatson: grub-install takes the GRUB_DISTRIBUTOR and truncates it at the first space and converts it to lower case for use as the efi bootloader_id... why is this? | 20:08 |
| hallyn_ | infinity: i'll take a look this week. I'm less than thrilled that it's a whole separate tree, but maybe it only has a few cleanly cherrypickable patches | 20:10 |
| hallyn_ | (i'll check the m-l for past submissions too) | 20:11 |
| hallyn_ | (hopefully tomorrow) | 20:11 |
| infinity | hallyn_: They're in the process of upstreaming it with a target of (I believe) 1.8, but pulling in a patch for 1.6 would be nice. | 20:11 |
| infinity | hallyn_: I haven't looked, but I'm hoping/assuming it's fairly self-contained. | 20:11 |
| hallyn_ | yup will give the backport a shot | 20:12 |
| hallyn_ | tjaalton: xserver-xorg-video-qxl built fine for my in chroot on porter-armhf. can you just add libxext-dev to build-deps? (I don't have upload rights) | 20:13 |
| infinity | What. The. Eff. | 20:13 |
| infinity | Alt-Right and Alt-Left have started swapping me between VCs. | 20:14 |
| infinity | This is seriously messing with my head, since that's also how I move between irssi windows. | 20:14 |
| psusi | infinity: did you hit sysrq-e? | 20:14 |
| infinity | Oh, I bet this is a consequence of running console-setup under my X session while fiddling with a chroot. | 20:14 |
| infinity | psusi: Definitely not. :) | 20:15 |
| infinity | This is remarkably jarring, though. | 20:15 |
| infinity | And Alt-F1 works from my X session without the need for the usual Ctrl modifier now. | 20:16 |
| infinity | Head explodey. | 20:16 |
| stgraber | infinity: that's fairly easy to fix, let me try to remember how | 20:17 |
| infinity | stgraber: I was thinking "toss hands in air; reboot". | 20:17 |
| infinity | And was already closing terminals to that end. :P | 20:18 |
| stgraber | kbd_mode can fix it for you | 20:18 |
| infinity | Probably. But I only reboot my laptop once a month anyway, it's due. | 20:18 |
| stgraber | infinity: sudo kbd_mode -s | 20:18 |
| infinity | stgraber: That did indeed fix it, though. Thanks. I'll try to remember that the next time I do this to myself. | 20:19 |
| infinity | (And now I'll reboot anyway, cause I like to see what explodes when I do) | 20:19 |
| infinity | Which reminds me... | 20:19 |
| infinity | Whose baby is the "waiting 300 minutes for your network configuration to happen" upstart job? | 20:19 |
| infinity | stgraber, slangasek: ? | 20:20 |
| slangasek | infinity: yes | 20:20 |
| stgraber | not mine, though usually when it happens it's my fault somehow ;) | 20:20 |
| slangasek | infinity: if you're actually waiting 300 seconds for your network configuration, it's because your network is misconfigured :P | 20:20 |
| infinity | Every time I accidentally leave eth0 in auto and then do something silly like reboot in an airport lounge, I have a sad. That could really do with an "I don't care, skip it" key, like fsck has. | 20:20 |
| stgraber | (since it should never appear if ifupdown/NM do their job) | 20:20 |
| infinity | slangasek: Yes, it's absolutely because I left something on auto and don't have a cable in. Not arguing otherwise. :) | 20:21 |
| infinity | slangasek: The "I don't care" key would still be nice, for idiots like me, and also for people who actually have a broken network and would like to get to the OS in a timely fashion to debug it. | 20:23 |
| infinity | Currently, I swear I can hear a tiny whip cracking and cackling in the distance while it says "your network is still broken, I shall punish you for another minute. hold please." | 20:23 |
| slangasek | infinity: ah, hmm. well, that would take some rejiggering of /etc/init/failsafe.conf to give it a way to listen for a key asynchronously | 20:24 |
| infinity | slangasek: Want a wishlist bug? | 20:29 |
| infinity | slangasek: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1247963 | 20:31 |
| ubottu | Ubuntu bug 1247963 in upstart (Ubuntu) "Would be nice to be able to cancel the wait for network configuation in failsafe.conf" [Wishlist,New] | 20:31 |
| stgraber | I'm not sure how the user interaction works within plymouth, but from an upstart point of view, we could do it by having failsafe.conf do "start failsafe-keypress &" with that job waiting for a keypress from plymouth and if it matches whatever we're looking for, emit static-network-up which will get failsafe.conf to exit and the boot to continue | 20:35 |
| === Ursinha-afk is now known as Ursinha | ||
| xnox | stgraber: we are already watching for some keypresses and emit events for those. E.g. "control-alt-delete" =) we could overload that job, to try emitting static-network-up ;-) | 20:42 |
| stgraber | well, in this case, I think it'd be much cleaner to get plymouth to forward the keypress (same thing as we do with mountall) than have upstart watch another obscure key combination :) | 20:44 |
| === salem_ is now known as _salem | ||
| jtaylor | can one fix gdb for python3 in saucy without recompiling gdb against python2? | 21:20 |
| slangasek | infinity: wishlist bug> well, that's not likely to be fixed unless you work on it, fwiw | 23:15 |
| RAOF | jtaylor: Yeah, mostly. You can run 2to3 on the gdb hook, and that worksish. | 23:19 |
| jtaylor | unfortunately not | 23:19 |
| jtaylor | that fixes the error in starting gdb | 23:19 |
| jtaylor | but the python plugins are still broken | 23:19 |
| jtaylor | I recompiled with py2 now, easier than figuring out how the plugins work :/ | 23:20 |
| slangasek | mmm? are you working on porting gdb's python support to py3? | 23:21 |
| jtaylor | no trying to debug python extension code | 23:21 |
| slangasek | ah | 23:21 |
| jtaylor | may I ask why gdb was changed? its not seeded | 23:21 |
| jtaylor | oh it is | 23:21 |
| slangasek | right, gdb is certainly in main at the very least :) | 23:22 |
| jtaylor | everything in main must now be python3? | 23:22 |
| slangasek | well, "must" | 23:23 |
| slangasek | we are in the process of deprecating python2 from main and have been for a couple of years already | 23:23 |
| slangasek | but it hasn't been the easiest transition in the wolrd | 23:23 |
| jtaylor | yes but gdb wasn't really ready for py3 yet | 23:23 |
| jtaylor | the python plugins are incredibly useful | 23:23 |
| slangasek | according to the changelog the change to support it was made upstream | 23:23 |
| slangasek | are the plugins part of the gdb source or from somewhere else? | 23:24 |
| jtaylor | I think they are part of python | 23:24 |
| slangasek | e.g.? | 23:24 |
| jtaylor | /usr/lib/debug/usr/bin/python2.7-dbg-gdb.py | 23:24 |
| slangasek | the equivalent scripts seem to exist in the python3.3-dbg package | 23:26 |
| jtaylor | tried those too, didn't really work | 23:26 |
| jtaylor | I didn't look into it much, just tried 2to3 and the python3 file, then I recompiled gdb | 23:27 |
| slangasek | I'm not familiar with how these are used, how can I reproduce the problem you're seeing (so I can help make sure it gets fixed)? | 23:27 |
| jtaylor | just needed to debug something rather quickly | 23:27 |
| jtaylor | if you start gdb you get a syntax error, and if the plugins are working you get nice python object resolving, e.g. http://paste.ubuntu.com/6361710/ | 23:28 |
| slangasek | if you start gdb how? | 23:28 |
| slangasek | when I run 'gdb' I get no such error | 23:28 |
| jtaylor | hm I get it everytime, do you have python-dbg installed? | 23:29 |
| slangasek | no - you mean installing python3.3-dbg, and running 'gdb' with no target, is sufficient to reproduce the problem? | 23:29 |
| jtaylor | let me just revert my gdb | 23:29 |
| jtaylor | ah no you have to debug python | 23:30 |
| slangasek | ok | 23:30 |
| jtaylor | http://paste.ubuntu.com/6361721/ | 23:30 |
| jtaylor | hm there is bug 1241668 | 23:31 |
| ubottu | bug 1241668 in python3.3 (Ubuntu Saucy) "gdb embeds python3.3, but support scripts are not compatible" [Medium,Triaged] https://launchpad.net/bugs/1241668 | 23:31 |
| jtaylor | the upstream patch does not work :/ | 23:33 |
| jtaylor | like 2to3 it just fixes the syntax errors but not the functionlity | 23:33 |
| slangasek | right, it seems like even /usr/lib/debug/usr/bin/python3.3dm-gdb.py is a python2 script, not a python3 script... I guess nobody was able to test this until recently because gdm didn't support python3 | 23:35 |
| slangasek | er, gdb | 23:35 |
| slangasek | jtaylor: so, how would I test the functionality? 2to3 lets me run gdb, and I can set a breakpoint on a C function but don't know how to use this to set a breakpoint on a python function | 23:41 |
| xnox | (there were bugs with it, but i thought is or in-process of being fixed and uploaded) | 23:42 |
| xnox | third party plugins non-with-standing... | 23:42 |
| jtaylor | slangasek: break e.g. in PyTuple_Size | 23:42 |
| slangasek | Python Exception <class 'AttributeError'> 'PyDictObjectPtr' object has no attribute 'items': | 23:43 |
| jtaylor | the frame should show the content of the tuple if the plugin works | 23:43 |
| slangasek | I guess that's the issue? | 23:43 |
| jtaylor | yes | 23:43 |
| slangasek | righto | 23:43 |
| jtaylor | one of them, depending on what feature is used you get different errors | 23:43 |
| jtaylor | upstream issue is http://bugs.python.org/issue19308 | 23:46 |
| jtaylor | the patch there does not seem to work (commented on it) | 23:46 |
| barry | oh my, look at all the python going on here | 23:47 |
| StevenK | barry: O HAI. If you have a second, care to weigh in on https://bugs.launchpad.net/launchpad/+bug/1050173 ? | 23:52 |
| ubottu | Ubuntu bug 1050173 in Launchpad itself "bugwatches set to accepted closed in python.org roundup maps to 'fix committed' not 'fix released'" [High,Triaged] | 23:52 |
| slangasek | fwiw that looks suspiciously like a bug in the gdb support, to me... why does it want 'items' instead of 'iteritems' (the function that's provided by the class in this script, even for python2)? | 23:53 |
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!