| === tai271828_ is now known as tai271828 | ||
| hallyn | dannf: there's an extra patch in there, qemu-Add-virQEMUCapsSetGICCapabilities.patch, which is not in series? | 00:32 |
|---|---|---|
| hallyn | dannf: other than that, nope, pls feel free. | 00:33 |
| hallyn | pitti: thx - have you figured out my moronic mistake yet? :) | 01:00 |
| hallyn | i was wrong before btw - i thought that this succeeded in xenial, and maybe with libvirt it did, but with my test pkgs it just fails differently in xenial. | 01:01 |
| cjwatson | s390x builders back up; took a bit longer than expected, but there were no builds to be delayed | 01:49 |
| === Son_Goku_ is now known as Son_Goku | ||
| === marcusto_ is now known as marcustomlinson | ||
| hallyn | pitti: I find that if I manual rm the Alias symlink (/etc/systemd/system/pkg2.service) that seems to fix it | 04:58 |
| hallyn | suggesting that i can simply in libvirt-bin.preinst do an rm -f /etc/systemd/system/libvirtd.service (the old alias) | 05:01 |
| hallyn | dannf: if you push that new libvirt pkg could you also toss in http://paste.ubuntu.com/16503889/ ? | 05:08 |
| cpaelzer | good morning | 06:09 |
| pitti | good morning | 06:45 |
| pitti | bdmurray: FTR, I reviewed all items in xenial-proposed queue, and they now all have something to complain about; the exception is pollinate which I uploaded myself, would be nice if you could review this? | 08:13 |
| jamespage | pitti, apologies for those no-op MIR's - I'll make sure ddellav and coreycb pickup on those before they get to the SRU team in future... | 08:25 |
| jamespage | MIR/SRU's | 08:25 |
| * jamespage has not had enough coffee yet) | 08:25 | |
| pitti | jamespage: no worries -- should they be rejected? | 08:28 |
| jamespage | pitti, yes please - I've marked the xenial bug tasks as won't fix | 08:28 |
| pitti | ack, done | 08:29 |
| jamespage | pitti, thanks... | 08:29 |
| happyaron | pitti: waiting asac to add me to ~network-manager... so I can change the repo ownership | 08:43 |
| pitti | happyaron: ah great, thanks for updating it | 08:43 |
| Laney | doko: libpeas question - can you remember why you multiarched manually instead of setting the libdir? | 09:30 |
| pitti | apw, sil2100: vivid-proposed has had linux-flo and linux-mako for > 250 days now (see http://people.canonical.com/~ubuntu-archive/pending-sru.html); are these orphaned and shoudl be removed, or released? | 09:31 |
| apw | pitti, a good question indeed ... i am guessing they have been copied (if needed) out to the overlay ... | 09:36 |
| pitti | apw: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=linux&field.status_filter=published&field.series_filter=vivid | 09:37 |
| pitti | no, they haven't | 09:37 |
| pitti | apw: however, jibel said that "These kernel have been on flo and mako for a while, marking as verification done." | 09:38 |
| pitti | jibel: ^ do the images build with vivid-proposed enabled? | 09:38 |
| Laney | barry: ^^^ AFAICT this is going to break since libpease-1.0-0 is M-A: Same | 09:41 |
| Laney | libpeas-1.0-0 | 09:41 |
| * Laney is struggling to think why the loaders can't be multiarched | 09:42 | |
| === pkern_ is now known as pkern | ||
| === greyback is now known as greyback|bbiab | ||
| sil2100 | pitti: hmm, need to take a look | 10:00 |
| sil2100 | pitti: yes, our images build with -proposed enabled IIRC | 10:01 |
| sil2100 | pitti: actually these packages are not used during image builds but during the android package build | 10:02 |
| sil2100 | And since our silos have -proposed enabled, they have been used by our devices since long | 10:02 |
| sil2100 | pitti: so I would also opt for releasing them | 10:02 |
| pitti | ah | 10:03 |
| pitti | sil2100: ok, makes sense; I just didn't want to release them blindly and introduce a new kernel on touch all of a sudden | 10:03 |
| sil2100 | I'm triple confirming in the logs now | 10:03 |
| pitti | apw: no objections from your side either? | 10:03 |
| mvo | bdmurray: hi, could you please have a look at the snapd sru in the queue and let me know if there is anything missing on our end? | 10:04 |
| sil2100 | Give me a minute for firefox to un-hang itself ;) | 10:04 |
| pitti | mvo: I commented on the bug already | 10:04 |
| pitti | bdmurray: ^ | 10:04 |
| pitti | sil2100: not urgent at all :) | 10:04 |
| mvo | pitti: oh, great | 10:04 |
| pitti | mvo: also, 2.0.4 regresses tests in yakkety, so it didn't land; this could likely also affect xenial? | 10:05 |
| mvo | pitti: on bug #1583085 or a different one? | 10:05 |
| pitti | mvo: bug 1576287 | 10:05 |
| sil2100 | Get:1 http://ftpmaster.internal/ubuntu/ vivid-proposed/universe linux-image-3.4.0-7-mako armhf 3.4.0-7.39~15.04.1 [8138 kB] <- yeah, looks like the one from -proposed | 10:06 |
| sil2100 | pitti: if apw has no objections then 'ship it!' | 10:06 |
| sil2100 | :) | 10:06 |
| pitti | mvo: #1583085 isn't even mentioned in the SRU changelog | 10:06 |
| pitti | sil2100: thanks for quadruple-checking :) | 10:06 |
| mvo | pitti: thanks, I will do a 2.0.5 that clarifies the point you mention there then | 10:07 |
| pitti | mvo: no need for a version bump, but if you upload a 2.0.5 to yakkety anyway, sure | 10:07 |
| pitti | mvo: btw, cleaner to have 2.0.5 in devel and 2.0.5~16.04 as backport | 10:07 |
| mvo | pitti: yeah, there is a 2.0.5 planned anyway so I will just fold it all in | 10:09 |
| mvo | pitti: thanks again | 10:09 |
| caribou | Q: when a package makes a modification to the default grub config, should it trigger a grub-update or just warn the user about the need to update grub ? | 10:09 |
| pitti | mvo: no worries, *hug* | 10:10 |
| apw | caribou, the kernel tells grub, but it does cheat as in it supplies hooks which grub itself ties into | 10:11 |
| caribou | apw: yeah, I do the same for kdump-tools to build the smaller initrd.img | 10:11 |
| caribou | apw: but postinst only triggers the build of the small initrd.img; in this case, I'm adding crashkernel= to the boot param | 10:12 |
| caribou | apw: what kexec-tools used to do. Hmm, I should check what was done by kexec-tools & do the same | 10:13 |
| apw | caribou, yeah, i would expect you to be calling update-grub i suspect | 10:13 |
| Odd_Bloke | pitti: smoser: I'm seeing a ~6 minute hang on boot after a "systemd-udevd[459]: seq 1648 '/devices/pci0000:00/0000:00:03.0/virtio0/net/ens3' is taking a long time" message in syslog, with "cloud-init-local.service @1.034s +7min 17.851s" in `systemd-analyze critical-chain`; what can I do to further work out what's going on here? | 10:15 |
| Odd_Bloke | pitti: smoser: (I'm assuming this is something to do with the conversations you were having in Austin; I can give you SSH access to a machine exhibiting this problem if you want :) | 10:16 |
| pitti | Odd_Bloke: at first sight this sounds like cloud-init blocking uevents | 10:16 |
| pitti | Odd_Bloke: in Austin we indeed figured out how to avoid that, but I guess that change isn't in xenial (or even yakkety) yet | 10:17 |
| Odd_Bloke | (This is yakkety, I should add) | 10:17 |
| pitti | bug 1577844 | 10:18 |
| * pitti nudges ubottu | 10:18 | |
| pitti | Odd_Bloke: so, this is almost surely https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844 | 10:18 |
| caribou | apw: indeed that's what kexec-tools.postinst does | 10:18 |
| Unit193 | bug 1577844 in cloud-init (Ubuntu) "Drop unnecessary blocking of all net udev rules" [Medium,Triaged] https://launchpad.net/bugs/1577844 | 10:21 |
| Odd_Bloke | pitti: OK, so presumably I would expect to see this on xenial as well? | 10:23 |
| pitti | Odd_Bloke: yes | 10:23 |
| pitti | Unit193: oh, are you playing ubottu now? :-) | 10:23 |
| Unit193 | :) | 10:24 |
| Odd_Bloke | Or is ubottu playing Unit193? :p | 10:24 |
| pitti | let the Turing test begin | 10:24 |
| === hikiko is now known as hikiko|ln | ||
| caribou | pitti: is there a 'smart' way to run DEP8 tests on debian (equivalent to adt-buildvm-ubuntu-cloud) using qemu virt ? | 10:41 |
| doko | Laney, because then the loaders dir changes as well. I wasn't sure what would need changing too. so best thing would be change it as well, and rebuild all things having loaders | 10:45 |
| Laney | doko: you can't have external loaders, so I think it's okay | 10:47 |
| === marcusto_ is now known as marcustomlinson | ||
| rbasak | caribou: there are instructions in the adt-virt-qemu manpage | 10:53 |
| caribou | rbasak: thanks; didn't think to look there :) | 10:53 |
| Laney | doko: unless you can think of any other reasons, I'll do a full multiarch in Debian & then sync, if that's okay? | 10:54 |
| doko | Laney, sure, but there's still #815727 | 10:55 |
| doko | but I assume that's addressed with your rationle | 10:55 |
| doko | rationale even | 10:55 |
| Laney | yup | 10:56 |
| Laney | I was trying to figure out why you did it that way | 10:56 |
| === hikiko|ln is now known as hikiko | ||
| === JanC is now known as Guest23785 | ||
| === JanC_ is now known as JanC | ||
| pitti | hallyn: I followed up to bug 1579922, but you pretty much figured it out already (I used d-s-h to also clean up in the Debian specific enablement tracking, although that's not really that important) | 12:04 |
| pitti | hallyn: and it's far from moronic, this is way more complicated than it ougth to be.. | 12:04 |
| crocodilehunter | where the devs at? | 12:17 |
| cpaelzer | Hi, I've seen the following in my builds quite often - is there something I e.g. can/should add to build dependencies to avoid that? | 13:05 |
| cpaelzer | dpkg-distaddfile: warning: File::FcntlLock not available; using flock which is not NFS-safe | 13:05 |
| === _salem is now known as salem_ | ||
| cpaelzer | googling for it hit so many build logs that the obvious solution (if ther is one) is hidden behind them | 13:05 |
| smoser | Odd_Bloke, why would it be 6 minutes ? | 13:14 |
| Odd_Bloke | smoser: I have no idea. :) | 13:15 |
| asac | happyaron: to lp? | 13:16 |
| smoser | Odd_Bloke, where did you see this ? | 13:17 |
| Odd_Bloke | smoser: Vexxhost. | 13:18 |
| GunnarHj | Hi bdmurray, could you please move the SRU at bug #1575555 to -updates? Affects quite a few users. | 13:19 |
| barry | Laney: yeah. unfortunately i doubt i'll be able to finish that before pycon. i got pulled into another project that has higher priority. :/ | 13:19 |
| happyaron | asac: yep, so I can put the git repos under the team, :) | 13:37 |
| mvo | pitti: I uploaded a new 2.0.5 version that fixes the issues you mentioned | 13:38 |
| pitti | ah, still with +16.10 .. unusal version number for devel | 13:38 |
| pitti | mvo: thanks! | 13:39 |
| mvo | pitti: our target right now is still xenial, thats where this comes from, but yeah, easy to enough if it really bothers someone :) | 13:40 |
| pitti | cjwatson: I tested http://paste.ubuntu.com/16506628/ locally as much as possible (with local britney.py b2 run and running the sed locally), and it works; does that look halfway sensible? | 13:40 |
| caribou | pitti: when DEP8 tests run on the builders using qemu virt, are the qemu images rebuilt each time ? | 13:41 |
| cjwatson | cpaelzer: no, just ignore it | 13:41 |
| cjwatson | pitti: I think so, but you'll also need something elsewhere to save the output somewhere useful | 13:41 |
| pitti | cjwatson: isn't the new output_notest.txt rsynced to people.u.c? | 13:42 |
| cjwatson | pitti: bit more complicated than that, look at the stats function | 13:42 |
| pitti | cjwatson: I actually can't sudo -u ubuntu_archive -i any more on lillypilly, might be that this got moved somewhere? | 13:42 |
| cjwatson | pitti: also there's no rsync involved, lillypilly does proxypass to snakefruit | 13:43 |
| cjwatson | pitti: ubuntu-archive@lillypilly is gone | 13:43 |
| cjwatson | pitti: you just need to put the files somewhere plausible in $HTML in the stats function | 13:43 |
| pitti | cjwatson: ah, so snakefruit:~ubuntu-archive/public_html is "the thing" | 13:43 |
| cjwatson | yep | 13:43 |
| pitti | cjwatson: understood, thanks | 13:43 |
| pitti | cjwatson: http://paste.ubuntu.com/16506661/ | 13:45 |
| pitti | cjwatson: I deliberately didn't archive it yet, I don't think it's very useful (if we want it later, we can still add it) | 13:45 |
| pitti | cjwatson: archive> $HTML/update_excuses/$SERIES/$NOW | 13:45 |
| pitti | actually, only doing that for the devel series would suffice, and save some time | 13:46 |
| pitti | so, adding a [ "$SERIES" = "$DEFAULT_SERIES" ] | 13:46 |
| cjwatson | pitti: that seems fine; the archives are very large as it is | 13:48 |
| cjwatson | pitti: oh, one other thing | 13:48 |
| cjwatson | pitti: the output from this all gets dumped into the raw log, and I think it might be confusing to have the two runs in succession | 13:49 |
| pitti | cjwatson: next iteration: http://paste.ubuntu.com/16506698/ | 13:49 |
| cjwatson | pitti: I think the notest run should be >/dev/null 2>&1 | 13:49 |
| cjwatson | or at least >/dev/null | 13:49 |
| pitti | cjwatson: good point; I'd do one run as-is, check that everything works as intended, and hten commit the >/dev/null ? | 13:49 |
| cjwatson | pitti: first if there should have an else block that rms output_notest.txt | 13:50 |
| cjwatson | rm -f that is | 13:50 |
| cjwatson | otherwise it'll get confusing when a series goes from default to non-default | 13:50 |
| pitti | cjwatson: ah, that applies to both if's actually | 13:50 |
| asac | happyaron: ok done | 13:51 |
| asac | thanks | 13:51 |
| cpaelzer | cjwatson: thanks! | 13:53 |
| pitti | cjwatson: http://paste.ubuntu.com/16506747/ | 13:54 |
| pitti | cjwatson: (I can locally drop the >/dev/null for debugging on snakefruit if needed); I also dropped the -v, no point with >/dev/null | 13:54 |
| dannf | hallyn: oh, good catch. and yeah - i'll add that patch for ya. | 13:55 |
| cjwatson | pitti: LGTM | 13:56 |
| pitti | cjwatson: thanks for your review! | 13:56 |
| hallyn | pitti: it seems like a sort of 'deb-systemd-helper rename-service pkg1.service pkg2.service new-package' would be helpful | 14:06 |
| hallyn | pitti: in libvirt it's a bit simpler bc we restart on upgrade, | 14:06 |
| hallyn | but if we didn't want to restart - as in lxcfs - then this would be even more complicated | 14:07 |
| pitti | hallyn: yeah, then it gets hairy, as you remove the unit from the disk, so you can never restart it ; i. e. this basically needs a reboot (or a way to restart it after all) | 14:08 |
| hallyn | pitti: but so when i have libvirt-bin.service provided by libvirt-bin pkg, and an upgrade doesn't have libvirt-bin.service; does the upgrade not turn off and disable the libvirt-bin.service? | 14:10 |
| pitti | hallyn: no, debhelper can't know that an earlier package version used to ship a unit that doesn't exist any more | 14:11 |
| pitti | hallyn: i. e. there could certainly be some debhelper/dpkg-maintscript helper for this, but it needs to be declared explicitly | 14:11 |
| hallyn | heh, sure it can, we have the technology :) I thought prerm and postrm would do it | 14:11 |
| hallyn | ok. | 14:11 |
| hallyn | clearer then | 14:12 |
| hallyn | thanks! | 14:12 |
| pitti | well, we could pry it out of the /var/lib/systemd/deb-systemd-helper-enabled/ data | 14:12 |
| pitti | but that doesn't have information which package shipped a service, so no | 14:13 |
| hallyn | ... dpkg -S knows... | 14:13 |
| pitti | at most, preinst could iterate over the previous .deb contents and disable stuff that disappeared, but that's well within "flaky heuristics/overcomplicated" territory I think | 14:13 |
| pitti | so I think explicitly declaring this is more practical (also given how rare this is) | 14:14 |
| hallyn | ok | 14:14 |
| pitti | but that declaration should be much easier than writing the preinst code etc. yourself | 14:14 |
| hallyn | actually what i think surprised me most was finding out that aliases are stored... under /etc. | 14:15 |
| hallyn | so /etc/systemd is where deb-systemd-helper stores its info? | 14:15 |
| pitti | hallyn: well, not speicifcally for d-s-helper | 14:15 |
| pitti | that's where systemd itself stores its info | 14:15 |
| pitti | /var/lib/systemd/deb-systemd-helper-enabled/ is just a helper to see whether or not to enable newly appearing services during upgrades | 14:16 |
| pitti | hallyn: yes, Alias= translates to nothing more than a symlink in /e/s/ for the new name | 14:16 |
| pitti | cjwatson: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt \o/ | 14:25 |
| pitti | and the world didn't explode, it didn't clobber HeidiResult, and stuff with regressions didn't get promoted | 14:25 |
| cjwatson | great | 14:25 |
| pitti | cjwatson: thanks for your help! | 14:25 |
| cjwatson | np | 14:26 |
| pitti | doko: FYI: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt | 14:26 |
| caribou | pitti: when running DEP8 tests with adt-run, one can provide the --show-boot to the qemu runner, is it possible to have that done systematically by the builders ? | 14:27 |
| caribou | pitti: in short, is there a way to stipulate that in the source package ./debian/tests/control file ? | 14:28 |
| doko | pitti: nice. some for excuses? | 14:28 |
| bdmurray | pitti: was complaining about items in the xenial-proposed queue done in bugs? | 14:45 |
| karstensrage | thank you Laney !! | 14:50 |
| pitti | caribou: there isn't, as most virt backends don't actually have that option | 15:01 |
| pitti | bdmurray: yes, I followed up to the referenced bug reports; a few issues got sorted out in the meantime and rejected | 15:01 |
| caribou | pitti: k | 15:02 |
| pitti | doko: not right now, what would be the point? it's regular excuses if you ignore the tests | 15:03 |
| LocutusOfBorg | what happened to ppc64el builders? | 15:04 |
| pitti | bos01 cloud just died | 15:04 |
| pitti | autopkgtests on ppc64el are down too | 15:04 |
| bdmurray | pitti: Thinking about the process did you subscribe to those bugs? Should we tell people to really ping us after fixing stuff? | 15:05 |
| LocutusOfBorg | :( | 15:05 |
| pitti | bdmurray: I didn't subscribe, I was just going to look again when I reprocess; but sub'ing sounds better indeed, I'll do that from now on | 15:06 |
| cjwatson | impressive, I can't even sync logs from the ppa-manage unit | 15:06 |
| pitti | even "nova list" is hanging | 15:06 |
| bdmurray | pitti: Maybe we should put that in the SRU process then | 15:08 |
| LocutusOfBorg | also almost all the arm64 build started some minutes ago are stuck in the fetch of gcc-4.9 | 15:08 |
| cjwatson | yes they're in the same cloud. | 15:08 |
| LocutusOfBorg | thanks | 15:10 |
| seb128 | wtf | 15:56 |
| seb128 | sil2100, seems like you are copying some sort of overlay over to yakkety? | 15:57 |
| Laney | barry: I'll upload what is (hopefully) a syncable version to unstable, and you can pick it up when ready | 15:57 |
| barry | Laney: +1. won't be until after pycon for me tho | 15:58 |
| Laney | no biggy | 15:58 |
| seb128 | sil2100, unping | 15:58 |
| sil2100 | seb128: yeah, a batch copy of binaries, now will proceed with doing source copies for projects that had no-change rebuilds | 15:59 |
| seb128 | sil2100, I though one was reverting some xenial changes but I got confused by the changelog | 15:59 |
| sil2100 | (mentioned it on -release just in case there are any objections) | 15:59 |
| hallyn | dannf: so, just to be sure, you're going to push that? Or were you wanting me to? | 15:59 |
| showaz | zabbix 3.x (agent) not work 15.04/16.04 | 16:11 |
| dannf | hallyn: already did :) | 16:11 |
| hallyn | dannf: rockin' :) thanks | 16:13 |
| hallyn | then i can move on to qemu merge | 16:13 |
| tdaitx | bdmurray: regarding 1566201, I can't reproduce the error locally, I just get a message: | 16:18 |
| tdaitx | Unknown channel 'xenial-partner' | 16:18 |
| tdaitx | The channel 'xenial-partner' is not known | 16:18 |
| === mnepton is now known as mneptok | ||
| tdaitx | bdmurray: if I remove the "?channel=xenial-partner" param then a pop up "Install additional software" comes up and I can install it normally | 16:21 |
| bdmurray | tdaitx: cyphermox and I are working on it | 16:21 |
| tdaitx | bdmurray: nice, let me know if you need some testing... I'm not running unity though, I wonder if that is why I can't reproduce it... | 16:22 |
| bdmurray | tdaitx: what was the command line you are using? | 16:23 |
| tdaitx | bdmurray: the one from the bug report (with sudo) | 16:29 |
| tdaitx | bdmurray: let me know if I should test without sudo (I have a private ppa entry in sources.list.d that is unreadable for any other use besides sudo and apt tools fail to work because of that) | 16:30 |
| tdaitx | * s/besides sudo/besides root/ | 16:31 |
| mvo | bdmurray: if you could have a look at todays snapd 2.0.5 sru upload, that would be great | 16:59 |
| bdmurray | mvo: okay | 17:00 |
| GunnarHj | bdmurray: Thanks. :) | 17:19 |
| LocutusOfBorg | I hope you will catch the arm64/ppc64el soon :) | 17:41 |
| * LocutusOfBorg leaves | 17:43 | |
| bdmurray | dosaboy: From which archive did you test the fix for bug 1578351? The clould archive or the official ubuntu one? | 17:45 |
| ubottu | bug 1578351 in keystone (Juju Charms Collection) "mitaka ksclient fails to connect to v6 keystone" [High,Fix committed] https://launchpad.net/bugs/1578351 | 17:45 |
| egsome | I'm thinking in creating a simple application which hooks into Apport to track program crashes and retrieve possible solutions from AskUbuntu and other websites. What do You think about that ? | 17:45 |
| bdmurray | egsome: When you say solutions do you mean workarounds / hacks or updated packages to install which fix the crash? | 17:46 |
| egsome | bdmurray, All of them. Workarounds, Hacks and Packages to install or update. | 17:47 |
| dobey | i think that's a bad idea | 17:47 |
| dobey | workarounds/hacks are unsupportable, and can possibly cause problems when fixed packages are available | 17:47 |
| egsome | dobey, Great, Why then ? | 17:48 |
| egsome | dobey, OK, You're right, and that what would be displayed to the user, to be careful while using any of these solutions. | 17:48 |
| dobey | and it perpetuates a problem we have with random people on the internet giving bad information to users | 17:49 |
| egsome | dobey, But, What actually happens for most of Ubuntu users, is their being looking for answers ( Hacks, Workarounds, .. ) simply in Google once they face a crash or a problem. | 17:49 |
| dobey | "be careful" isn't enough | 17:49 |
| dobey | if you want to make the situation better, then the better thing to do would be to help fix the crashes and get the fixes landed in ubuntu and then SRUed out to the stable releases | 17:50 |
| egsome | dobey, Users would be able to see the possible solutions / workarounds, also the comments written on them, and maybe the rating of the answer ( Stack Overflow ). | 17:50 |
| egsome | dobey, Fixing the bugs is something important, which I don't consider as part of the idea I'm talking about. The idea simply make the Ubuntu Community closer to new users and even old Ubuntu users. | 17:52 |
| dobey | well, for one, there shouldn't be anything on askubuntu about "solving" crashes, because bug reports are off topic for ask ubuntu, so any question about a crash should be closed as off topic, and tell the person to report a bug | 17:53 |
| dobey | sending mroe people to askubuntu to be turned away because they're asking off topic things, is not the right way to do whatever it is you're trying to do :) | 17:54 |
| egsome | dobey, I'm not going to send people to AskUbuntu, I'm just developing a tool that queries AskUbuntu and similar resources for possible workarounds and solutions. | 17:54 |
| egsome | dobey, OK, Let's talk about an issue like nm-applet being closed or "hidden" as most users express. | 17:55 |
| dobey | express? | 17:55 |
| egsome | dobey, I remember I saw lot of questions on AskUbuntu about it, and people talking about how to get it back, is that also off-topic ? I'm not sure, just asking. | 17:56 |
| egsome | dobey, Sorry, I mean "as most users say or consider it is just getting hidden not crashed" | 17:56 |
| dobey | while there may be a serious issue related to network-manager in 14.04 as the result of some other update, trying to generalize the sitaution to all problems isn't helpful. | 17:56 |
| egsome | dobey, I'm using 16.04 and nm-applet also crash for specific situations. | 17:57 |
| dobey | well yes, any software running on any comptuer can crash for many reasons | 17:57 |
| dobey | it doesn't mean that you are prescient of those reasons or can somehow determine what to query askubuntu or other sites for | 17:58 |
| nacc | does askubuntu even export an API to search all questions? | 17:58 |
| dobey | nacc: yes, SE has an API | 17:58 |
| egsome | dobey, I mean that such a tool can be useful in such cases, nm-applet crash, Apport dialog appear with possible solutions or workarounds like how to get it running again. | 17:58 |
| nacc | dobey: ah ok, thanks | 17:58 |
| nacc | egsome: but i think the underlying question is how do you determine "possible solutions or workarounds"? | 17:59 |
| egsome | dobey, While that happen, the bug report already sent, and fixing the bug is the most important mission have to be done. | 17:59 |
| nacc | egsome: as in, how do you know what is the root cause of the bug? | 17:59 |
| dobey | egsome: askubuntu has no idea what crash reports are. the only way apport could associate a crash with a question would be if the question had a pre-existing crash report, and apport could find and match that data | 17:59 |
| dobey | egsome: otherwise, it's just an arbitrary search, and it's only going to add confusion to the problem | 17:59 |
| egsome | nacc, Apport collect lot of details about the crash, I'm sure that can be done in accurate way, maybe not the best, but would save lot of time, as I think. | 18:00 |
| nacc | dobey: well- (better-than-me)-said | 18:00 |
| dobey | egsome: askubuntu, ubuntu forums, google, etc… have no idea about the contents of crash reports | 18:00 |
| dobey | so you can't query them to find "possible solutions" | 18:00 |
| egsome | dobey, Sure I'll not search using the whole report ! I'd get use of the keywords to get the closest possible question. | 18:01 |
| dobey | egsome: the only 'keywords' you could use are the package name. which as i said, is a general search and not going to be helpful here | 18:01 |
| egsome | dobey, Sorry, It is not the only one at all ! Apport reports include lot of details even the error message if available, all of that can be used for the querying ! | 18:02 |
| dobey | egsome: well then just go do it. why did you ask what others think if you don't wnat to listen to any dissenting opinions? :) | 18:03 |
| egsome | dobey, I don't want to listen ?? I wouldn't come here to discuss at all if I don't want to listen ! I'm just discussing the points You mention, which I think the main objective of being in this channel, development-related discussions. | 18:04 |
| nacc | egsome: in open source development, code speaks louder than words, fwiw :) | 18:04 |
| egsome | dobey, Anyway, I'm sorry if I have been annoying somehow, and I'm open for any discussion related to the idea I told. | 18:05 |
| dobey | apport does a retrace on the crash reports server, not on the client. people don't go digging into the .crash files to find the stack trace signature when asking questions on askubuntu | 18:05 |
| egsome | nacc, That's a fact nacc, but discussing with others before coding is very important, to be capable of focusing our efforts on the right track. | 18:05 |
| dobey | they ask general things like "i have no network, how do i get it back?" | 18:05 |
| nacc | egsome: it would be interesting to see, if given your crash in apport, you can extract enough useful information to query askubuntu for relevant articles | 18:06 |
| egsome | nacc, That's exactly the core of my idea. | 18:06 |
| nacc | egsome: right, so do that for one specific case and see if it can work? | 18:06 |
| nacc | egsome: i disagree, in this case, re: discussing before coding | 18:07 |
| nacc | egsome: you can always rewrite | 18:07 |
| dobey | i'm just saying it's not feasible, because askubuntu doesn't know anything about crash reports. and your idea assumes that it does, and that there is useful information there related to how to "fix" the issues | 18:07 |
| nacc | egsome: but you've chosen a relatively difficult problem to get "right" | 18:07 |
| nacc | egsome: so it's better to try it first, see if it's tractable at all, then discuss, with that demo in hand | 18:07 |
| TJ- | Great project to rope in a DNN though! | 18:07 |
| dobey | i'm just pointing out all the difficulties you'll have to overcome to get something remotely close to what you want | 18:08 |
| egsome | dobey, Can You have a look here ? http://askubuntu.com/search?q=nm-applet include 539 questions mentioning nm-applet, not just "Network tray icon is not there". So, Crashes related to nm-applet would have 539 results to get the closest one using rest of the keywords provided in Apport crash report. | 18:08 |
| nacc | crashes != questions, as mentioned above -- they should be in bugs if they are crashes (and the question would have been closed, iiuc) | 18:09 |
| egsome | nacc, I agree with You. I think a working demo is required to have more clear discussions. And sure re-writing is always possible. | 18:09 |
| TJ- | egsome: if it helps you decide, I've been working on something similar, albeit with different aims, for 6 months now, and it is a very nuanced challenge to crack - artifical intelligence is the only way to have a chance | 18:09 |
| dobey | and if we had that, we wouldn't even need moderators on askubuntu any more, because the AI would be smart enough to close questions as spam, duplicates, off-topic, whatever | 18:11 |
| TJ- | you give AI too much credit... this is far harder than winning a game of a Go :) | 18:11 |
| nacc | skynet. | 18:11 |
| egsome | TJ-, I love AI, and I think Machine Learning can be used a lot to make that solution more smart and can decide more what to suggest to the user. Can I have a look at what You done so far if it is open-source ? I can even continue working on it with You if it is OK. | 18:12 |
| TJ- | egsome: it's not open (yet) and it's very different in aim (it processes live streams of data ) | 18:12 |
| dobey | TJ-: my point exactly. if you had an AI that can understand the nuances of English, and the very bad English which is used on the Internet at that, then it would be good enough to be a moderator | 18:12 |
| nacc | i mean in some sense what you are describing is an 'expert system' for ubuntu bugs, which could take as input some 'bug report' and spit out from all data sources 'relevant data'. Sort of like a good google search :) | 18:13 |
| TJ- | dobey: as I told egsome in #ubuntu, any solution would need a lot of curating too | 18:14 |
| TJ- | to make such a system effective the training needs to be done by expert bug solvers who can recognise solutions from misguided shotgun approaches | 18:15 |
| jcastro | egsome: I think a generic AU scope would be useful | 18:16 |
| jcastro | we used to have one, and when it worked it was awesome | 18:16 |
| dobey | well, the suggested thing would be useless for the discussed situation where egsome is claiming it would be useful. if network-manager is crashing, and thus the applet has gone away, then there is no network, so apport would be unable to query AU anyway | 18:17 |
| egsome | TJ-, Exactly, Training is a key to success of such system. | 18:17 |
| jcastro | right, I'm just saying, if you ignore the crasher part, it's a good idea | 18:17 |
| nacc | dobey: :) | 18:17 |
| nacc | jcastro: good point, it's really two tools -- get stuff from crasher (unclear if it's possible) and query AU (useful) | 18:18 |
| TJ- | it'd be great for folks using Chrome and wondering why the backspace key no longer goes back through the history, though :) | 18:18 |
| egsome | jcastro, How it would be aware of the current issue user is facing without using the crash reports ? | 18:19 |
| egsome | jcastro, To be just as a Searching Tool for AU ? | 18:19 |
| nacc | egsome: don't try to solve too much :) | 18:20 |
| nacc | egsome: in one tool | 18:20 |
| dobey | askubuntu-mode.el | 18:20 |
| egsome | nacc, Do You mean to ignore the Crash analysis part ? Don't know, feel like it would be just a searching tool. | 18:22 |
| nacc | egsome: right | 18:23 |
| nacc | do *two* tools | 18:23 |
| nacc | egsome: there are two separate problems, as jcastro points out | 18:23 |
| nacc | or problem-spaces, i guess | 18:23 |
| egsome | nacc, One for analyzing the apport reports, and other for searching Communities of Ubuntu ? | 18:23 |
| nacc | right | 18:24 |
| egsome | nacc, Isn't Google enough for the second one ? I mean that second one can just be useful if integrated with the first one. | 18:24 |
| nacc | then your solution is just tying them together by passing data from one to the other, presumably | 18:24 |
| nacc | egsome: if so, then work on the first problem, but i don't think it is | 18:24 |
| nacc | given some input, i dont' think google gives you the most relevant results | 18:24 |
| nacc | or even knows what relevancy is, beyond its own algorithms | 18:25 |
| egsome | nacc, Sure it doesn't, I've to do lot of work to make it capable of searching for the problem included in the Apport report. | 18:25 |
| dobey | google is a pretty poor search engine any more | 18:25 |
| dobey | but good if you like living in a bubble | 18:25 |
| egsome | I think it is a good idea to begin with the part of analyzing Apport reports. I'm thinking in hooking into it using the py hooks available, and get the info of each report, and try to get out the primary keywords that can be useful in searching for the solutions or workarounds. | 18:26 |
| === mfisch is now known as Guest76268 | ||
| TJ- | egsome: maybe see https://launchpad.net/+tour/api | 18:31 |
| nacc | dobey: true | 18:33 |
| ogra_ | sounds more llike another frontend to errors.ubunntu.com | 18:33 |
| egsome | TJ-, Thanks, I'm writing now a simple Apport hook in Python, trying to get a deeper idea of the structure of 'report' object passed. I hope it is well structured. | 18:33 |
| ogra_ | *http://errors.ubuntu.com | 18:34 |
| nacc | egsome: --^ may want to look at htat too | 18:34 |
| ogra_ | which already maps crashes to bugs | 18:34 |
| nacc | yep | 18:35 |
| egsome | nacc, ogra_, Going to have a look at that. | 18:35 |
| nacc | and there's tooling,i think, to add new rules to help it along | 18:35 |
| dobey | errors.u.c has restricted permissions because crashes may contain private info | 18:36 |
| nacc | which goes back to my previous point of how much information do you legitimately expose of the user's crash data to do these queries... | 18:36 |
| dobey | basically, as little as possible, and only over secure transports | 18:37 |
| nacc | yep | 18:40 |
| dosaboy | bdmurray: i tested both xenial-proposed and trusty-proposed/mitaka (UCA) so should be good to go | 19:19 |
| bdmurray | dosaboy: Got it, thanks for clarifying in the bug. | 19:23 |
| dosaboy | bdmurray: np | 19:23 |
| === Guest76268 is now known as mfisch | ||
| === salem_ is now known as _salem | ||
| mwhudson | i have a vaguely general question, this failed build https://launchpad.net/ubuntu/+source/golang-github-hpcloud-tail/1.0.0+git20160415.b294095-3/+build/9686605 is blocking -proposed migration | 21:09 |
| mwhudson | i don't really care about this package, i care even less about it on powerpc but i want to get it off the excuses page | 21:09 |
| mwhudson | i think the best way to do this would be to remove the binary from yakkety-release and then it can continue to ftbfs on powerpc | 21:10 |
| mwhudson | infinity, slangasek: does this ^ sound plausible? needs an AA presumably | 21:10 |
| slangasek | mterry: does require an AA, yes; is generally a reasonable solution for per-arch build failures that we don't expect to see fixed, provided there's a specific reason why; in this case golang-github-mitchellh-packer-dev also depends on it so you'd need to go up the chain an remove revdeps too | 21:18 |
| slangasek | hum | 21:18 |
| slangasek | mwhudson: does require an AA, yes; is generally a reasonable solution for per-arch build failures that we don't expect to see fixed, provided there's a specific reason why; in this case golang-github-mitchellh-packer-dev also depends on it so you'd need to go up the chain an remove revdeps too | 21:18 |
| mterry | :) | 21:18 |
| mwhudson | :-) | 21:18 |
| mwhudson | ok | 21:18 |
| mwhudson | surely golang-github-mitchellh-packer-dev is an _all package? | 21:18 |
| mwhudson | huh no it isn't | 21:19 |
| mwhudson | well that's strange | 21:19 |
| mwhudson | oh it's never built on powerpc though | 21:19 |
| slangasek | ah | 21:20 |
| slangasek | ok then | 21:20 |
| slangasek | (and yes, actually the -dev package is arch: all, so that's fine anyway) | 21:20 |
| mwhudson | slangasek: file a bug, subscribe ~ubuntu-archive or can you just jfdi? | 21:20 |
| mwhudson | btw looking into build failures in odd situations is a good way of finding hilarious bugs | 21:21 |
| slangasek | mwhudson: for this particular build failure, why is golang-golang-x-sys-dev apparenly so broken? | 21:21 |
| mwhudson | https://github.com/golang/go/issues/15738 <- my favourite bug of recent months | 21:21 |
| mwhudson | slangasek: it just doesn't have support for powerpc | 21:21 |
| slangasek | ok | 21:22 |
| mwhudson | it's an inherently arch/os dependent package | 21:22 |
| mwhudson | it could be added | 21:22 |
| slangasek | good argument for removing the binary | 21:22 |
| slangasek | removed | 21:22 |
| mwhudson | thanks | 21:22 |
| mwhudson | i chased s390x support in golang-golang-x-sys-dev in via debian yesterday :) | 21:22 |
| === _salem is now known as salem_ | ||
| * mwhudson afk for a while | 21:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!