| === zigo is now known as Guest59427 | ||
| cpaelzer | good morning | 05:30 |
|---|---|---|
| === marcusto_ is now known as marcustomlinson | ||
| doko | Mirv: looking at https://launchpadlibrarian.net/289272540/buildlog_ubuntu-yakkety-amd64.qliss3d_1.4-2_BUILDING.txt.gz | 05:48 |
| doko | there's a X11 header check, but it looks like it's triggered by CHECK_QT4, so some qt4 dev package seems to be missing an x11 -dev dependency | 05:49 |
| Mirv | doko: I haven't spent many minutes with Qt 4 since initial 2012 qtchooser work, but there is just two dev packages libqt4-dev and libqt4-opengl-dev. the former does recommend libqt4-opengl-dev that depends on Mesa dev than depends on X11 dev | 06:00 |
| Mirv | it does not seem there would be anything related changed in Debian after last Ubuntu merge | 06:01 |
| doko | Mirv: ok, adding libx11-dev gets me one step further: https://launchpadlibrarian.net/289273657/buildlog_ubuntu-yakkety-s390x.qliss3d_1.4-2ubuntu1_BUILDING.txt.gz | 06:02 |
| doko | now complaining about missing shared qt libs | 06:02 |
| doko | Mirv: add the libqt4-opengl-dev b-d doesn't help | 06:08 |
| Mirv | so it has built in Debian six months ago, before qt4-x11 4.8.7+dfsg7. dfsg7 added -std=gnu++98 as a workaround for GCC6, maybe that could affect something negatively | 06:14 |
| pitti | Good morning | 06:15 |
| Mirv | or as it's using autotools for some reason, they'd need to be updated or qmake used instead (there is qliss3d.pro in addition to the autotools files) | 06:16 |
| handsome_feng | Hi, gays, Good morning !Because of some issues found in test today, we have updated the theme package, Could anyone help to upload this: package: ubuntukylin-theme, Code : https://code.launchpad.net/~zctgbhu/ubuntukylin-theme/16.10 Release: https://launchpad.net/ubuntukylin-theme/16.10/1.6.2 , Thank you ! | 06:39 |
| doko | Mirv: ahh, that's failing because *no* libs can be found in /usr/lib anymore ;-P | 06:53 |
| doko | ++ ls '/usr/lib/*.a' | 06:54 |
| doko | + QT_IS_STATIC= | 06:54 |
| doko | + test x = x | 06:54 |
| doko | + QT_IS_STATIC=no | 06:54 |
| doko | + test xno = xno | 06:54 |
| doko | ++ ls '/usr/lib/*.so' | 06:54 |
| doko | + QT_IS_DYNAMIC= | 06:54 |
| doko | + test x = x | 06:54 |
| doko | + as_fn_error 0 '*** Couldn'\''t find any Qt libraries' 4119 5 | 06:54 |
| doko | + as_status=0 | 06:54 |
| doko | so this qt config test is horribly broken :-/ | 06:55 |
| === Guest59427 is now known as zigo | ||
| tmus | I've disabled resolved completely, using dnsmasq instead. But if I connect to a VPN, the domain provided as "dns-search" from the VPN server, is the ONLY domain that's resolved by the DNS on the VPN connection, causing a lot of things to not work... Can I send ALL DNS queries the way of the VPN? | 09:02 |
| tmus | This worked fine in 16.04 | 09:02 |
| === zumbi_ is now known as zumbi | ||
| pitti | tmus: could be fallout from bug 1592721 | 09:11 |
| ubottu | bug 1592721 in network-manager (Ubuntu Xenial) "Don't write search domains to resolv.conf in the case of split DNS" [Medium,Fix released] https://launchpad.net/bugs/1592721 | 09:11 |
| pitti | tmus: NM uses dnsmasq by default again in 16.10, FTR | 09:11 |
| tmus | pitti, good to hear that resolved was pulled - i like the idea, but not ready yet imho... | 09:13 |
| pitti | tmus: it's still being used on the server | 09:13 |
| pitti | tmus: for NM we need a proper DNS plugin for split-horizon DNS, which didn't exist until two weeks ago | 09:14 |
| pitti | we'll get that in Z | 09:14 |
| tmus | pitti, cool... | 09:14 |
| pitti | tmus: but your issue sounds like an NM-internal change (the above bug) | 09:14 |
| tmus | having read through the bug, this is clearly related, but not the same problem | 09:17 |
| tmus | For my VPN (this particular VPN anyway), i'm not split-tunnelling. Still, only DNS requests to my VPN's primary search-domain goes to the VPN DNS | 09:18 |
| tmus | (we have a looot of internal domains - but only the primary resolves correctly) | 09:18 |
| tmus | looking through syslog, it's clear that dnsmask is asked to use the VPN provided DNS servers *only* with the provided search-domain | 09:19 |
| tmus | actually it may be the same but now that i'm reading it the second time | 09:20 |
| tmus | pitti, can I msg you 10 lines of log to explain? | 09:26 |
| pitti | tmus: you can, but I suggest to put them on the bug instead and discuss there (busy with release stuff) | 09:26 |
| tmus | pitti, fair enough :) | 09:28 |
| pitti | cpaelzer: btw, you need https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=40cb56b9 as well if you have any tests that reboot | 09:57 |
| cpaelzer | thanks pitti | 10:03 |
| cpaelzer | pitti: I was broken on s390 due to other things then, but happy on amd64 with my tests that did not include reboots | 10:03 |
| seb128 | mardy, hey, is https://errors.ubuntu.com/problem/cdb7a4fc6d47e3ba3ce18606745c27933f9a7f57 something you are aware of? it's the n°1 error on e.u.c for 16.10 | 10:26 |
| seb128 | could be a qt issue, webbrowser seems to have a similar report | 10:27 |
| === dosaboy_ is now known as dosaboy | ||
| seb128 | Mirv, ^ do you know about those reports? | 10:28 |
| mardy | seb128: I really wasn't, thanks | 10:28 |
| seb128 | mardy, yw | 10:28 |
| mardy | Mirv: it's QNetworkManager, and happens during destruction... | 10:31 |
| mardy | Mirv: the first reports are from Oct 2nd and happen with older versions of signon too. So I guess it's due to some Qt landing... | 10:34 |
| seb128 | mardy, Mirv, webbrowser has the same issue so it would suggest a qt bug rather than a signon one | 10:35 |
| Mirv | seb128: yes, bug #1630765 , happens after bug #1618590 got fixed. there's silo 2054 that is in QA's hands that includes a cherry-pick from Qt 5.8 which however upstream doesn't seem suitable for their 5.6 criteria, but we might accept that workaround | 10:49 |
| ubottu | bug 1630765 in webbrowser-app (Ubuntu) "webbrowser-app crashed with SIGSEGV in QNetworkConfiguration::~QNetworkConfiguration()" [Medium,Confirmed] https://launchpad.net/bugs/1630765 | 10:50 |
| ubottu | bug 1618590 in Canonical System Image "scoperunner crashed with SIGSEGV in QObject::disconnect()" [Critical,Fix committed] https://launchpad.net/bugs/1618590 | 10:50 |
| Mirv | latest discussion about what the workaround would be hiding is at https://codereview.qt-project.org/#/c/172173/ , thanks to Michael from our side for providing valgrind trace to upstream | 10:50 |
| seb128 | k | 10:51 |
| seb128 | which I guess means it's not going to be fixed for release | 10:51 |
| Mirv | I guess no. reverting to the previous version would bring the scoperunner crash-on-exit back. | 10:51 |
| Mirv | ubuntu-qa: have you started looking at silo 2054 for desktop (and xenial+overlay phone)? | 10:52 |
| davmor2 | Mirv: nope still in the queue | 10:52 |
| Mirv | I was hoping there'd be a real fix by now, but it starts to look like we'd need to stop unloading those plugins | 10:52 |
| === hikiko is now known as hikiko|ln | ||
| === hikiko|ln is now known as hikiko | ||
| morf | hi | 12:34 |
| morf | is it possible to install ubuntu mobile to samsung galaxy s5 (klte)? | 12:34 |
| === _salem is now known as salem_ | ||
| pragomer_1 | Getting error "/init line 7 can't open /dev/sr0 no medium found" when booting via pxe.. here's my menu-entry:http://pastebin.com/3EJ4cPdp Whats wrong? | 13:11 |
| ginggs | tseliot: the libcuda-8.0-1 provides seems to have fallen out of the nvidia driver somewere between 361 and 367 | 14:27 |
| bdmurray | jbicha: Why did you reopen the yakkety task for bug 1619188? | 14:32 |
| ubottu | bug 1619188 in casper (Ubuntu Yakkety) "Unattended upgrades can break persistent live media" [Medium,Triaged] https://launchpad.net/bugs/1619188 | 14:32 |
| jbicha | bdmurray: because I assumed it was broken on yakkety too, but I'll re-close it now | 14:33 |
| bdmurray | jbicha: I just booted a yakkety live cd again and -security is commented out and the script is +x so its good. | 14:34 |
| jbicha | bdmurray: good, I'm glad yakkety works at this point :) | 14:38 |
| tseliot | ginggs: I don't recall removing it, or maybe I simply imagined adding that? | 14:45 |
| tseliot | ginggs: BTW, is that only for yakkety? | 14:45 |
| tseliot | I actually said "I have just uploaded your changes", so it's just me losing that change somehow | 14:47 |
| ginggs | tseliot: yes, it is only for yakkety (for now - maybe commit to git for xenial and include with next upload so we can put cuda in backports) | 14:50 |
| tseliot | ginggs: ok, thanks | 14:50 |
| ginggs | i was definitely in 361 https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-361/361.45.11-0ubuntu4 | 14:51 |
| ginggs | *it | 14:51 |
| tseliot | ginggs: yes, I probably used a slightly older branch as a base when creating the one for the 367 series | 14:54 |
| tseliot | ginggs: uploaded. I managed to find the same commit from the 361 branch. Go figure... | 15:12 |
| ginggs | tseliot: thanks! | 15:16 |
| tseliot | thanks for making me notice | 15:16 |
| === timrc_ is now known as timrc | ||
| === salem_ is now known as _salem | ||
| === imcleod is now known as imcleod-mtg | ||
| === _salem is now known as salem_ | ||
| nacc | can anyone see clearly why osgearth and qgis haven't migrated from trusty-proposed to trusty? All other archs have, and update_excuses/update_output say they are 'successful' and in the 'final' list. | 16:17 |
| nacc | sorry, specifically on armhf only | 16:18 |
| chiluk | cyphermox.. debdiffs in lp 1631474 ... modified per your recomendation.... I also did a bit more testing.. | 16:39 |
| ubottu | Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,In progress] https://launchpad.net/bugs/1631474 | 16:39 |
| chiluk | not exactly what you asked for, but I felt it flowed better this way.. I claim personal preference.. I also improved the comment in case the next guy doesn't think like I do. | 16:39 |
| === salem_ is now known as _salem | ||
| slangasek | nacc: that sounds somewhat related to the changes pitti was just making to britney this week | 16:50 |
| slangasek | nacc: oh, also, I'm not sure if we actually do migration of binaries using proposed-migration for stable releases | 16:50 |
| slangasek | it might require a manual copy | 16:50 |
| nacc | slangasek: ok, i was just surprised the other archs migrated but armhf hadn't | 16:53 |
| nacc | slangasek: maybe it just needs a manual poke? should i be asking #ubuntu-release instead? | 16:53 |
| slangasek | nacc: no, #ubuntu-release is busy with releasing ;) I'm having a look at these | 16:54 |
| Laney | nacc: I think they're just random builds that happened after the release | 16:54 |
| slangasek | nacc: "the other archs migrated" - except they didn't, because what Laney said | 16:54 |
| nacc | slangasek: yeah, i was hesitant to interject there today :) | 16:54 |
| nacc | Laney: ah | 16:54 |
| Laney | We deleted some similar ones in xenial earlier today | 16:54 |
| Laney | Not sure how they got retried; didn't think that was available for released suites (but ICBW there) | 16:55 |
| nacc | ok, had a user in #ubuntu wonder why qgis wasn't installable on armhf in trusty | 16:55 |
| nacc | Laney: except for osgearth, it's not a rebuild? or do you meant something else | 16:56 |
| Laney | Build failure that later succeeded | 16:56 |
| nacc | ah! | 16:56 |
| nacc | slangasek: Laney: thanks for the explanation! | 16:57 |
| slangasek | nacc: ah yeah I can't work out how to actually copy these in to trusty-updates, because copy-package operates on source packages and there is no source in trusty-proposed. Punting until a launchpad wizard can look at it (post-release) | 17:00 |
| slangasek | (my best idea so far is to copy the source /back/ from trusty release into trusty-proposed, so that there's then a source package that can be copied; but that sounds like a good way to make launchpad very angry about publication history) | 17:01 |
| infinity | slangasek: copy-package -e $ver --force-same-destination --from-suite=trusty-proposed -b foo | 17:03 |
| nacc | slangasek: ack, i'll put it on my todo to follow-up on later | 17:03 |
| slangasek | infinity: when the source was never previously in trusty-proposed? | 17:03 |
| infinity | slangasek: If it ever existed in trusty-proposed, LP will magically find it and put it back. | 17:03 |
| slangasek | ah | 17:03 |
| slangasek | ok | 17:03 |
| slangasek | yeah this is "random arch build caught up post-release" | 17:03 |
| slangasek | so it was never in -proposed | 17:03 |
| slangasek | errr wait | 17:03 |
| infinity | Sure it was. | 17:03 |
| slangasek | everything builds in -proposed these days | 17:03 |
| infinity | EVerything starts out in proposed. | 17:03 |
| slangasek | hee | 17:03 |
| slangasek | thanks | 17:03 |
| nacc | smoser: heh, your cloud-utils import kind of forced me to rethink the solution we had. It's now a bit more abstracted in the code and handles your particular case better (it was a real bug in the old implementation). When we do a source patch, we need to do it anywhere we might encounter that published version, including when we are lookingat the parents of a new import | 17:05 |
| slangasek | Copy candidates: | 17:05 |
| slangasek | <hang> | 17:05 |
| slangasek | ah there it is | 17:06 |
| smoser | nacc, so uploaded ? | 17:06 |
| nacc | smoser: testing my fix now :) | 17:06 |
| smoser | you have a feel / guess for how many packages might need "source patch" ? | 17:06 |
| nacc | smoser: and then need to actually clean up my changelog etc, but i think it's working | 17:06 |
| nacc | smoser: so far we've hit 3 | 17:07 |
| smoser | 3/~50 | 17:07 |
| smoser | :-( | 17:07 |
| nacc | smoser: yep | 17:07 |
| nacc | smoser: not great, not terrible (IMO) | 17:07 |
| smoser | $ proxy curl --silent http://archive.ubuntu.com/ubuntu/dists/xenial/main/source/Sources.xz | xzcat | grep ^Package: | wc -l | 17:13 |
| smoser | 2470 | 17:13 |
| smoser | 6% failure rate on 2400 packages is 144 | 17:13 |
| smoser | without touching universe. so yeah, maybe its not bad, but if in fact we have to manually patch 144 things, that sucks. | 17:14 |
| nacc | and i'm not sure it's on my roadmap to support importing all of main :) | 17:15 |
| nacc | as of right now, i'm focused on server packages | 17:15 |
| nacc | i'm not saying it's not a problem | 17:16 |
| smoser | what about just going on ? | 17:16 |
| smoser | warn: could not import package at version X. | 17:17 |
| nacc | then we'd have an inaccurate history | 17:17 |
| nacc | there are algorithmic guarantees we are trying to assert :) | 17:17 |
| nacc | we do orphan packages in some cases | 17:17 |
| smoser | --allow-failed-imports | 17:17 |
| smoser | given the archive seems to have started rejecting things like that, its probably mostly a historic problem. | 17:18 |
| nacc | it's exclusively historic | 17:18 |
| nacc | smoser: feel free to file a bug :) as of right now, i'm not convinced it's a large enough issue to warrant adding a flag, or changing the algorithm again | 17:19 |
| smoser | nacc, alternatively i could convince you otherwise by changing that pipe command above to just loop over usd-import <package> | 17:20 |
| smoser | and file individual bugs :) | 17:20 |
| nacc | that would also be fine | 17:21 |
| === _salem is now known as salem_ | ||
| nacc | smoser: it would be interesting to run that with --no-push, tbh, it'll probably take a few days to complete | 17:23 |
| === salem_ is now known as _salem | ||
| * smoser tries | 17:25 | |
| nacc | smoser: ok, cloud-utils can import with my fix(es). Want me to push now, or are you ok with waiting while I clean up my changelog | 17:29 |
| smoser | nacc, not really a hurry | 17:30 |
| smoser | just if i'm going to look at code now, i first run usd-import | 17:31 |
| nacc | smoser: ok, i should be able to push in about 20 minutes, it's not that complicate of a change, i just want to verify it a bit | 17:31 |
| jderose | chiluk: something seems slightly wonky with latest initramfs-utils from your PPA (at least for my use case); i added a comment to the bug | 17:43 |
| chiluk | thanks jderose | 17:44 |
| chiluk | jderose: can you get me full console log output?... | 17:44 |
| jderose | chiluk: yeah, what's the best way to do this? | 17:45 |
| chiluk | check to see if the errors are showing in /var/log/syslog or kern.log.. I suspect neither. | 17:46 |
| jderose | chiluk: or what's the place to dump this from if i don't have a serial console setup? after the boot i can mount a usb drive, copy it over to that | 17:46 |
| jderose | chiluk: okay, i'll just grab everything from /var/log | 17:46 |
| chiluk | dumping serial console would be the best .. as I don't think the messages you are seeing get dumped into /var/log | 17:47 |
| slangasek | nacc: so these packages are uncopiable, even with infinity's hint, with an error about 'binaries conflicting with the existing ones'. | 17:47 |
| jderose | chiluk: i'll try to get serial console smart in the mean time, but no promises :) | 17:47 |
| chiluk | that would be awesome jderose... | 17:48 |
| nacc | slangasek: hrm, that's odd, because rmadison says there are no binaries for armhf? | 17:49 |
| slangasek | nacc: certainly | 17:49 |
| chiluk | jderose what is your /proc/cmdline as well? | 17:49 |
| slangasek | nacc: it's a strange error, and there certainly should never have been /different/ binaries with the same version number | 17:49 |
| nacc | slangasek: agreed -- do you want me to file a bug? | 17:49 |
| slangasek | nacc: against launchpad, sure | 17:50 |
| nacc | slangasek: ok, thanks! | 17:50 |
| jderose | chiluk: "initrd=initrd.img-4.4.0-36-generic root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro nomodeset net.ifnames=0"... so the only "weird" thing i'm doing is using net.ifnames=0, not sure if that's effecting anything or not | 17:50 |
| chiluk | ah jderose I think what's happening is htat you are now going through the full all_net_bootable device bringup loop. | 17:53 |
| chiluk | which wasn't functioning correctly before. | 17:53 |
| jderose | chiluk: okay, so this is working as expected, despite making stuff take a bit longer? | 17:53 |
| chiluk | yeah ... jderose ... give me one second. | 17:54 |
| nacc | slangasek: LP: #1632800 | 17:54 |
| ubottu | Launchpad bug 1632800 in Launchpad itself "qgis and osgearth stuck in trusty-proposed for armhf" [Undecided,New] https://launchpad.net/bugs/1632800 | 17:54 |
| chiluk | jderose ... I'm going to give you a script to run on your machine .. we may have to strip out some additional devices. | 17:54 |
| chiluk | it also could just be possible that it's now trying all your devices for a dhcp server. | 17:54 |
| chiluk | instead of just the one you want. | 17:54 |
| jderose | chiluk: FYI, this was PXE booting a machine with one Ethernet and one WiFI nic | 17:57 |
| chiluk | jderose can you run http://paste.ubuntu.com/23313997/ for me? | 17:57 |
| chiluk | and tell me the output? | 17:58 |
| jderose | chiluk: is it okay to run it after the full boot completes, or does in need to be run early, like in the initramfs stage? | 17:58 |
| chiluk | after full boot should be good enough. | 17:58 |
| jderose | okay, just a sec... | 17:59 |
| chiluk | I just want to see if you have any odd devices.. | 17:59 |
| chiluk | and the order in which they come up. | 17:59 |
| chiluk | cyphermox... hold off for a second... Looking at jderose's use case .. | 17:59 |
| chiluk | yeah so looking into it jderose I suspect the initramfs may be attempting to bring up your wlan device as well. | 18:03 |
| chiluk | the solution to that would be using ip=:::::eth0:dhcp instead of simply ip=dhcp | 18:04 |
| chiluk | which is actually more correct than it was previously. | 18:04 |
| jderose | chiluk: you're script is just outputting "eth0" | 18:04 |
| chiluk | hmm. I expected you to have multiple devices.. | 18:06 |
| chiluk | and one failing. | 18:06 |
| chiluk | jderose: do you get the same errors if you use ip=:::::eth0:dhcp ?? | 18:09 |
| chiluk | jderose.. for your use case nothing much has changed between 8.3+lp1631474 and 8.3+lp1631474b2 .. | 18:11 |
| cyphermox | chiluk: too late. | 18:11 |
| chiluk | you should be following the same logic path with both commits. | 18:12 |
| chiluk | it's ok cyphermox.. I think we have something else at play here with jderose. | 18:12 |
| cyphermox | my guess is there are timeouts -- the right way to figure this out is to get all the logs | 18:13 |
| chiluk | cyphermox: does that mean you've made the upload? I think we are still safe with the debdiffs as they are currently in the bug. | 18:14 |
| cyphermox | yes, it's done, and yes, that part is correct | 18:14 |
| jderose | chiluk: okay, "ip=:::::eth0:dhcp" seems to work fine, no unexpected delay | 18:15 |
| jderose | but "ip=dhcp" still works differently than it previously did | 18:15 |
| chiluk | cyphermox ^^^ sounds to me like we're now correctly processing all_netbootable_devices .. | 18:16 |
| chiluk | but running all_netbootable_devices for him only yeilds eth0. | 18:17 |
| chiluk | which is odd. | 18:17 |
| cyphermox | what other devices are there? | 18:17 |
| chiluk | cyphermox: running all_netbootable_devices only shows eth0.. | 18:18 |
| chiluk | which is why I'm confused.. | 18:18 |
| chiluk | jderose you said there was a wireless card in there as well right? | 18:19 |
| cyphermox | yes, what other interfaces should there be? | 18:19 |
| jderose | cyphermox: just a wifi NIC, although `ifconfig -a` isn't actually showing the device for whatever reason | 18:19 |
| chiluk | probably lacks drivers | 18:19 |
| cyphermox | well, then that's the reason -- the driver is probably missing | 18:19 |
| cyphermox | "missing" == not loaded yet | 18:19 |
| chiluk | but that' doesn't explain why ip=dhcp causes errors where ip=:::::eth0:dhcp does not. | 18:20 |
| chiluk | at least for him. | 18:20 |
| jderose | maybe so. seems `wifi-tools` isn't install by default on ubuntu server, so that might be the problem too | 18:20 |
| chiluk | jderose what do you see in /sys/class/net/* ? | 18:21 |
| jderose | chiluk: just "eth0" and "lo" | 18:21 |
| cyphermox | jderose: please open a bug and add all the output you have on screen as you try to boot | 18:22 |
| jderose | cyphermox: sure, but i might not have time till tomorrow | 18:22 |
| chiluk | that's fine.. jderose.. something else is going on in your boot case.. | 18:24 |
| jderose | chiluk: gotcha, thanks. seems like i can just use "ip=:::::eth0:dhcp" and be fine | 18:24 |
| chiluk | feel free to ping me or cyphermox jderose when you have all thte logs grabbed. | 18:24 |
| jderose | okay, will do | 18:25 |
| === imcleod-mtg is now known as imcleod | ||
| dmj_s76 | infinity: In doing upgrade testing xenial->yakkety, the updater complains that it can't authenticate. Is that expected currently? | 18:42 |
| === buxy is now known as kalibot | ||
| === kalibot is now known as buxy | ||
| slangasek | dmj_s76: certainly not; can you be more specific? | 18:52 |
| dmj_s76 | So running do-release-upgrade -d | 18:53 |
| dmj_s76 | gpg: BAD signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>" | 18:54 |
| dmj_s76 | Authentication Failed | 18:54 |
| dmj_s76 | Authenticating the upgrade failed. There may be a problem with the network or with the server. | 18:55 |
| dmj_s76 | Similar authentication failure message when using the graphical updater | 18:55 |
| === buxy is now known as kalibot | ||
| === kalibot is now known as buxy | ||
| slangasek | dmj_s76: ok, could that mean that you have (or did have) a captive portal in the way that is corrupting the download? Do you see a similar failure from 'sudo apt update'? | 19:22 |
| chiluk | slangasek can I get sru approval for https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474 initramfs-tools ? you look to have approved the previous sru for initramfs-tools. | 19:41 |
| ubottu | Launchpad bug 1631474 in initramfs-tools (Ubuntu Yakkety) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [High,In progress] | 19:41 |
| slangasek | chiluk: ENOTIME; grab the sru staffer du jour? | 19:41 |
| chiluk | will do. | 19:41 |
| chiluk | I understand you guys are knee deep in release time. | 19:42 |
| dmj_s76 | slangasek: Actually checking into that | 20:01 |
| dmj_s76 | slangasek: apt update works fine | 20:03 |
| === ximion is now known as ximion-afk | ||
| tsimonq2 | Who is responsible for yaboot nowadays? | 20:41 |
| dmj_s76 | slangasek: infinity: Sorry to worry you guys. It was a caching issue on our network. | 21:17 |
| slangasek | dmj_s76: so I suspected, thanks for confirming :) | 21:17 |
| dmj_s76 | Had to wait to confirm on our end but wanted to give you a heads up in case it was an issue blocking testing for others | 21:18 |
| === tedg_ is now known as tedg | ||
| === mariogrip_ is now known as mariogrip | ||
| === michagogo_ is now known as michagogo | ||
| === zigo_ is now known as zigo | ||
| === karstensrage_ is now known as karstensrage | ||
| === NishanthMenon__ is now known as NishanthMenon | ||
| === ginggs_ is now known as ginggs | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| slavanap | I'm Windows developer. I want to implement Ubuntu File Manager right click extension. Where should I start? Which docs should I read first? | 23:23 |
| tsimonq2 | slavanap: I would join #ubuntu-desktop if I were you :) | 23:27 |
| cjwatson | This isn't my field, but I think "nautilus extensions" would probably be good search terms here | 23:28 |
| tsimonq2 | that too ^ | 23:28 |
| cjwatson | (and "apt search nautilus extension" shows several existing ones that you could perhaps use as example code - again, not my field so I don't know which ones are best) | 23:29 |
| === ximion is now known as ximion-afk | ||
| slavanap | tsimonq2, thanks for advice! :) | 23:34 |
| slavanap | cjwatson, got it! Thanks! | 23:35 |
| nacc | rbasak: took a while, but i think i've got the framework for upload/ tagging going now | 23:39 |
| nacc | rbasak: although something i've got is provoking a pygit2 segfault :) | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!