| === maclin1 is now known as maclin | ||
| === ahoneybun is now known as Guest36814 | ||
| === dax is now known as hax | ||
| === hax is now known as dax | ||
| === maclin1 is now known as maclin | ||
| pitti | Laney: I think http://autopkgtest.ubuntu.com/running has been stuck for a while; this page should grow a time stamp at the bottom | 06:43 |
|---|---|---|
| === klebers_ is now known as klebers | ||
| Laney | pitti: hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm! | 08:02 |
| pitti | Laney: amqp-status-collector might have crashed? | 08:03 |
| pitti | Laney: and good morning! | 08:03 |
| pitti | Laney: there is a cronjob which is supposed to restart it, but IIRC that didn't work for some reason | 08:04 |
| Laney | yes I'm in there | 08:04 |
| Laney | it crashed a little while ago | 08:05 |
| Laney | pitti: i restarted it manually & apw is checking why the cron thing didn't work | 08:16 |
| pitti | Laney: cheers | 08:16 |
| * Laney stabs tmux | 08:17 | |
| davmor2 | Laney: why what did tmux ever do to you...and use byobu instead :P | 08:19 |
| Laney | davmor2: it is via byobu | 08:20 |
| Laney | ah, F6 worked | 08:20 |
| davmor2 | Laney: I could of told you that :P | 08:20 |
| apw | F6 ... jez | 08:29 |
| bdrung_work | pitti, i tested apport-retrace. why is the source package needed? | 09:27 |
| pitti | bdrung_work: it creates a StacktraceSource: field; but that's not really essential, it could be made optinal | 09:56 |
| bdrung_work | pitti, the logic in _search_contents (packaging_impl.py) is broken. | 10:09 |
| bdrung_work | pitti, you assume the presence of specific Content-%s.gz files | 10:10 |
| bdrung_work | pitti, e.g. you try http://ftp.de.debian.org/debian/dists/jessie/Contents-amd64.gz, but that exists in the main, contrib, or non-free subdirectory | 10:13 |
| pitti | bdrung_work: ah, could very well be that this needs adjustment for debian's layout; for Ubuntu's, Contents is in that location (http://archive.ubuntu.com/ubuntu/dists/xenial/) | 10:14 |
| pitti | and not in the component/ dir | 10:14 |
| bdrung_work | that could be derived from the Release file | 10:15 |
| bdrung_work | or does apt provide this mapping information somewhere? | 10:15 |
| pitti | right, looking at Release sounds good | 10:21 |
| bdrung_work | pitti, i stumbled over another issue: 'apport.packaging.get_file_package(report[path]' make_sandbox() returns the wrong package name (since two different packages provide the same binary file) | 10:37 |
| pitti | bdrung_work: I suggest filing them as bugs, so that someone interested can work on those; I can help with reviewing MPs, but I can't/won't work on those myself | 10:39 |
| bdrung_work | pitti, any chance to get apport switched from bzr to git? | 12:07 |
| pitti | bdmurray: ^ any objections? I'm fine with that | 12:08 |
| bdrung_work | pitti, the naming of the config path is not very good | 12:14 |
| bdrung_work | example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845208 | 12:14 |
| ubottu | Debian bug 845208 in apport-retrace "apport-retrace crashed with IOError in _get_primary_mirror_from_apt_sources(): [Errno 2] No such file or directory: u'Debian GNU/Debian testing/sources.list'" [Normal,Open] | 12:14 |
| bdrung_work | or in my case "Debian GNU/Linux 8/sources.list" | 12:18 |
| slashd | rbasak : good morning, do you have any update about the isc-dhcp (split into 2 binary packages) LP: #1176046 ? | 12:36 |
| ubottu | Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046 | 12:36 |
| rbasak | slashd: see https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/46. I did try to ping you about that too. | 12:44 |
| ubottu | Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] | 12:44 |
| slashd | rbasak, reading | 12:45 |
| slashd | rbasak, will update the lp bug in a few minutes | 12:46 |
| === bregma__ is now known as bregma | ||
| === slashd- is now known as slashd | ||
| slashd | rbasak, done | 12:58 |
| slashd | rbasak, sorry for missing your update on Apr 11. | 13:00 |
| === caribou_ is now known as caribou | ||
| bdrung_work | pitti, first one: https://bugs.launchpad.net/apport/+bug/1684117 | 13:03 |
| ubottu | Launchpad bug 1684117 in Apport "apport-retrace determines wrong package providing a file" [Undecided,New] | 13:03 |
| rbasak | slashd: thanks. Just glancing at it now. | 13:06 |
| rbasak | slashd: in verif-xenial.debdiff, shouldn't the Replaces line be unversioned? | 13:06 |
| rbasak | slashd: currently I don't think it'll have any effect? | 13:07 |
| rbasak | slashd: if you do end up editing it, there are a couple of typos in d/changelog that you might as well fix while you're there. | 13:07 |
| pitti | bdrung_work: followed up on that one, please confirm | 13:07 |
| rbasak | slashd: also the xenial changelog needs a bug reference please. | 13:07 |
| pitti | bdrung_work: oh, nevermind | 13:08 |
| bdrung_work | pitti, do you still need more information? | 13:09 |
| bdrung_work | i can't give away my test case since that involves inhouse packages which i do not want to name | 13:10 |
| rbasak | slashd: also, please could you detail some upgrade tests in the bug description? Some variations of what to do on Trusty, upgrade to Xenial, and then what to check that the upgrade path worked as expected. Including things like not doing anything special on Trusty and installing -noddns on Trusty, and so on. I think these should be documented in the bug and explicitly checked during SRU verification. | 13:10 |
| bdrung_work | pitti, do you run any checks on the code? flake8? pylint? | 13:11 |
| rbasak | slashd: this is in respect of the packaging changes specifically, to check that the metadata does what we want it to do. Checking the binary behaves as expected needs verifying too, of course. | 13:11 |
| pitti | bdrung_work: nope, it's clear, I just missed the param; yes, test/run runs pyflakes and pycodestyle (and the tests of course) | 13:12 |
| slashd | rbasak, the upgrade worked on caribou and I test as noted on comment #42 --> https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/comments/42 ... but I'll detailed more if needed #2 for the typo, I'll review it and do the necessary modification #3 I'll add bug reference | 13:12 |
| ubottu | Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] | 13:12 |
| rbasak | slashd: I appreciate that you did it in comment 42. What I want is to make sure that it's done for SRU verification too, so the test plan should really be in the SRU information. | 13:13 |
| bdrung_work | pitti, and max line length = 99 chars? | 13:13 |
| slashd | rbasak, sure | 13:13 |
| rbasak | slashd: and of course if we change the Replaces, it'll need retesting. | 13:13 |
| pitti | bdrung_work: not enforced (see invocation in test/run), it just ignores the line len error (historic reason, would be fine to use --max-line-length) | 13:14 |
| slashd | rbasak, yep I'll give it a with a unversion Replaces: | 13:16 |
| slashd | rbasak, ok tks for your input | 13:16 |
| rbasak | jbicha: around? | 14:02 |
| rbasak | jbicha: in graphviz in the trusty queue... | 14:02 |
| rbasak | ...shouldn't the new dependency be (= ${binary:Version}) like the others? | 14:02 |
| rbasak | Looks like that's what you did for Xenial, and the binary is created from the same source? | 14:03 |
| rbasak | (and matches the others) | 14:03 |
| jbicha | rbasak: yes, are you to able to fix that? I don't have upload rights for graphviz/trusty and that's a very old SRU candidate now | 14:07 |
| rbasak | jbicha: sure, I'll fix up. Are you planning on doing SRU verification? As long as we have some volunteer. | 14:09 |
| jbicha | yes, the test case is pretty easy | 14:15 |
| rbasak | OK, thanks! | 14:15 |
| pitti | bdrung_work: btw, bug 1639427 might be your contents.gz issue? | 14:28 |
| ubottu | bug 1639427 in apport (Debian) "cannot determine package name from file" [Unknown,Confirmed] https://launchpad.net/bugs/1639427 | 14:28 |
| bdrung_work | pitti, nope. i patched that contents part | 14:30 |
| bdrung_work | oh, wait | 14:30 |
| bdrung_work | let me read that bug report | 14:31 |
| bdrung_work | pitti, that might be my contents.gz issue (but that manifested in a backtrace in my case) | 14:32 |
| bdrung_work | pitti, i have patches for the contents.gz issue in my git repository | 14:43 |
| bdrung_work | pitti, what do you prefer. Having CoreDumpFile which contains a string pointing to the core dump file or allow to specify a file in CoreDump? | 15:38 |
| pitti | bdrung_work: you can already have a file pointer in a Report object | 15:39 |
| pitti | bdrung_work: ... by assigning a tuple; see http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/problem_report.py#L315 for the format | 15:40 |
| bdrung_work | pitti, the thing is that i need to put the path into the file on disk | 15:40 |
| pitti | not a fan, I must say -- the point of .crash files is to be self-contained, and people copy them around (from a locked-down server to a desktop) to report them, etc. | 15:41 |
| pitti | apport-retrace has an option for specifying an external core dump | 15:41 |
| pitti | but if I have to pick, CoreDumpFile: for sure -- doing guesswork on a key is bad | 15:42 |
| nacc | rbasak: re: LP: #1684112, i think it'd actually be pretty straightforward | 15:42 |
| ubottu | Launchpad bug 1684112 in usd-importer "Cannot restrict import to supported releases only" [Wishlist,New] https://launchpad.net/bugs/1684112 | 15:42 |
| rbasak | nacc: thanks. But really, not urgent. It'll become moot when we import everything. | 15:43 |
| nacc | rbasak: yeah, understood, but also in the meanwhile it'd be nice ) | 15:43 |
| rbasak | :) | 15:43 |
| slashd | rbasak, I did the necessary modification and tests (re: LP: #1176046) | 15:45 |
| ubottu | Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046 | 15:45 |
| slashd | and update the lp bug accordingly | 15:45 |
| rbasak | slashd: thanks. I'll add it to my list | 15:45 |
| slashd | rbasak, thanks | 15:45 |
| pitti | bdrung_work: need to leave, cu tomorrow! | 15:47 |
| bdrung_work | cu | 15:48 |
| rbasak | slashd: I didn't mean to ask you to test the upgrade paths now. What I want is the SRU information to make it clear that they will be tested from the proposed pockets during SRU verification. | 16:19 |
| slashd | rbasak, ok but it's still worth it to test before anyway as an extra security and obviously I'll test again once in -proposed | 16:27 |
| rbasak | slashd: sure, but can you add this plan to the SRU information please? | 16:28 |
| rbasak | slashd: since some other ~ubuntu-sru may process this after verification is marked done, it should be made explicit in the bug exactly what we agreed needs to be tested. | 16:29 |
| slashd | rbasak sure | 16:29 |
| rbasak | Thanks! | 16:29 |
| slashd | rbasak, done | 16:31 |
| JonelethIrenicus | when trying to build apps what is init tool merge? | 16:42 |
| JonelethIrenicus | getting not found error | 16:42 |
| nacc | JonelethIrenicus: context? "build apps"? | 16:42 |
| JonelethIrenicus | nacc: build ubuntu unity 8 apps | 16:42 |
| nacc | JonelethIrenicus: ok, you might ask in a unity channel? (see /topic) | 16:45 |
| JonelethIrenicus | unity channel on freenode? | 16:47 |
| nacc | !alis | JonelethIrenicus | 16:48 |
| ubottu | JonelethIrenicus: Alis is an IRC service to help you find channels. For help on using it, see "/msg Alis help list" or ask in #freenode. Example usage: "/msg Alis list http" | 16:48 |
| JonelethIrenicus | does ubuntu still have an sdk channel for app development | 16:49 |
| JonelethIrenicus | nacc: any idea? | 16:54 |
| nacc | JonelethIrenicus: did you look in alis? | 17:01 |
| JonelethIrenicus | nacc: the giant list of channels? | 17:02 |
| nacc | JonelethIrenicus: you can search alis, did you read the faq above? | 17:03 |
| JonelethIrenicus | nacc: its in the topic | 17:04 |
| JonelethIrenicus | #ubuntu-app-devel | 17:04 |
| JonelethIrenicus | damn dude that was difficult | 17:04 |
| JonelethIrenicus | haha | 17:04 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| vtapia | ping rbasak | 17:20 |
| === JanC_ is now known as JanC | ||
| nacc | rharper: ooh, i think i finally got ppa imports working :) | 19:10 |
| rharper | nice! | 19:10 |
| === jasondotstar_ is now known as jasondotstar | ||
| nacc | rbasak: should we have patches-applied -devel branches? | 22:08 |
| nacc | rbasak: i can't see a reason not to, at least currently, but we don't | 22:10 |
| nacc | rharper: yep, it's working, i'm fixing up my commits and pushing | 22:34 |
| nacc | only about 273 insertions to add the new subcommand | 22:34 |
| nacc | some/most of which can be abstracted back out to common functions, tbh | 22:34 |
| rbasak | nacc: I think we absolutely should in order to meet the use case for patches-applied branches for drive-by contributors | 22:59 |
| rbasak | nacc: not sure about namespacing though | 22:59 |
| nacc | rbasak: yep, i can fix that now | 22:59 |
| nacc | rbasak: i think it'd fit with the rest of them, as-is | 22:59 |
| nacc | but i need to make sure the code can do it :) | 22:59 |
| rbasak | OK :) | 22:59 |
| nacc | rbasak: if around, have time for another quick question? | 23:43 |
| rbasak | nacc: o/ | 23:46 |
| nacc | rbasak: just so i don't forget, we need to figure out namespaces for import-ppa. Right now, push is disabled for it | 23:47 |
| nacc | but if it's meant to be say, ppa_nacc/.... in the lpusip repository (potentially) or lpmep (obviously possible) | 23:47 |
| nacc | that starts to leak into `usd clone` which brings in all the remote branches and tags | 23:47 |
| nacc | i think it's an argument for gitnamespaces so they don't collide | 23:48 |
| nacc | they will stitll share objects | 23:48 |
| rbasak | nacc: I've been swinging my opinion the other way and away from gitnamespaces as it happens. We should figure out the use cases and then see if we can come up with a single namespace plan that can encompass them | 23:50 |
| nacc | rbasak: yeah, the alternative it to not do the remap we do now | 23:50 |
| nacc | where the 'lpusip' remote gets the branches put into refs/heads | 23:50 |
| nacc | i'm not sure | 23:50 |
| rbasak | nacc: we might be able to adjust things with sensible push and fetch refspecs | 23:50 |
| nacc | rbasak: yeah, that's what i'm struggling to come up with | 23:51 |
| nacc | i'm pushing what i have now, as it doesn't change anything | 23:51 |
| rbasak | nacc: HO tomorrow? | 23:51 |
| nacc | well, with regards to this issue | 23:51 |
| nacc | but maybe .. | 23:51 |
| nacc | yeah | 23:51 |
| nacc | :) | 23:51 |
| nacc | and we can just hammer it out | 23:51 |
| nacc | i think the primary issue is we have too many special cases :) | 23:51 |
| nacc | and so we just need a 'policy' for what the git refspec should look like generally that's unambiguous to determine where a given refs/head or refs/tags comes from | 23:52 |
| rbasak | More generally, it should be what "owns" the name, rather than where it comes from. | 23:52 |
| nacc | fwiw, with the latest push, we have the 'namespace' stored in one place in antying that deals with a git repository now | 23:53 |
| rbasak | I think. | 23:53 |
| nacc | so we have a better means of doing something with that value easier (chagnes/improvements) | 23:53 |
| nacc | rbasak: err, yes 'owns' in the process sense, yep | 23:53 |
| nacc | rbasak: the primary thing i was getting mixed up on is that both lpusip and lpmep can have, say, ubuntu/devel branches | 23:53 |
| nacc | and we don't want them to accidentally mix | 23:53 |
| rbasak | http://pad.ubuntu.com/git-importer-namespaces | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!