=== zigo is now known as Guest59427
[05:30] <cpaelzer> good morning
=== marcusto_ is now known as marcustomlinson
[05:48] <doko> Mirv: looking at https://launchpadlibrarian.net/289272540/buildlog_ubuntu-yakkety-amd64.qliss3d_1.4-2_BUILDING.txt.gz
[05:49] <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
[06:00] <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:01] <Mirv> it does not seem there would be anything related changed in Debian after last Ubuntu merge
[06:02] <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:08] <doko> Mirv: add the libqt4-opengl-dev b-d doesn't help
[06:14] <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:15] <pitti> Good morning
[06:16] <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:39] <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:53] <doko> Mirv: ahh, that's failing because *no* libs can be found in /usr/lib anymore ;-P
[06:54] <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:55] <doko> so this qt config test is horribly broken :-/
=== Guest59427 is now known as zigo
[09:02] <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
=== zumbi_ is now known as zumbi
[09:11] <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:13] <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:14] <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:17] <tmus> having read through the bug, this is clearly related, but not the same problem
[09:18] <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:19] <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:20] <tmus> actually it may be the same but now that i'm reading it the second time
[09:26] <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:28] <tmus> pitti, fair enough :)
[09:57] <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
[10:03] <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:26] <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:27] <seb128> could be a qt issue, webbrowser seems to have a similar report
=== dosaboy_ is now known as dosaboy
[10:28] <seb128> Mirv, ^ do you know about those reports?
[10:28] <mardy> seb128: I really wasn't, thanks
[10:28] <seb128> mardy, yw
[10:31] <mardy> Mirv: it's QNetworkManager, and happens during destruction...
[10:34] <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:35] <seb128> mardy, Mirv, webbrowser has the same issue so it would suggest a qt bug rather than a signon one
[10:49] <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:50] <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:51] <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:52] <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
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
[12:34] <morf> hi
[12:34] <morf> is it possible to install ubuntu mobile to samsung galaxy s5 (klte)?
=== _salem is now known as salem_
[13:11] <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?
[14:27] <ginggs> tseliot: the libcuda-8.0-1 provides seems to have fallen out of the nvidia driver somewere between 361 and 367
[14:32] <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:33] <jbicha> bdmurray: because I assumed it was broken on yakkety too, but I'll re-close it now
[14:34] <bdmurray> jbicha: I just booted a yakkety live cd again and -security is commented out and the script is +x so its good.
[14:38] <jbicha> bdmurray: good, I'm glad yakkety works at this point :)
[14:45] <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:47] <tseliot> I actually said "I have just uploaded your changes", so it's just me losing that change somehow
[14:50] <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:51] <ginggs> i was definitely in 361 https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-361/361.45.11-0ubuntu4
[14:51] <ginggs> *it
[14:54] <tseliot> ginggs: yes, I probably used a slightly older branch as a base when creating the one for the 367 series
[15:12] <tseliot> ginggs: uploaded. I managed to find the same commit from the 361 branch. Go figure...
[15:16] <ginggs> tseliot: thanks!
[15:16] <tseliot> thanks for making me notice
=== 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_
[16:17] <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:18] <nacc> sorry, specifically on armhf only
[16:39] <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.
=== salem_ is now known as _salem
[16:50] <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:53] <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:54] <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:55] <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:56] <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:57] <nacc> slangasek: Laney: thanks for the explanation!
[17:00] <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:01] <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:03] <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:05] <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:06] <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:07] <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:13] <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:14] <smoser> without touching universe. so yeah, maybe its not bad, but if in fact we have to manually patch 144 things, that sucks.
[17:15] <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:16] <nacc> i'm not saying it's not a problem
[17:16] <smoser> what about just going on ?
[17:17] <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:18] <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:19] <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:20] <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:21] <nacc> that would also be fine
=== _salem is now known as salem_
[17:23] <nacc> smoser: it would be interesting to run that with --no-push, tbh, it'll probably take a few days to complete
=== salem_ is now known as _salem
[17:25]  * smoser tries
[17:29] <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:30] <smoser> nacc, not really a hurry
[17:31] <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:43] <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:44] <chiluk> thanks jderose
[17:44] <chiluk> jderose: can you get me full console log output?...
[17:45] <jderose> chiluk: yeah, what's the best way to do this?
[17:46] <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:47] <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:48] <chiluk> that would be awesome jderose...
[17:49] <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:50] <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:53] <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:54] <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:57] <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:58] <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:59] <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 ..
[18:03] <chiluk> yeah so looking into it jderose I suspect the initramfs may be attempting to bring up your wlan device as well.
[18:04] <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:06] <chiluk> hmm. I expected you to have multiple devices..
[18:06] <chiluk> and one failing.
[18:09] <chiluk> jderose: do you get the same errors if you use ip=:::::eth0:dhcp ??
[18:11] <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:12] <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:13] <cyphermox> my guess is there are timeouts -- the right way to figure this out is to get all the logs
[18:14] <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:15] <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:16] <chiluk> cyphermox ^^^ sounds to me like we're now correctly processing  all_netbootable_devices ..
[18:17] <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:18] <chiluk> cyphermox: running all_netbootable_devices  only shows eth0..
[18:18] <chiluk> which is why I'm confused..
[18:19] <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:20] <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:21] <chiluk> jderose what do you see in /sys/class/net/*   ?
[18:21] <jderose> chiluk: just "eth0" and "lo"
[18:22] <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:24] <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:25] <jderose> okay, will do
=== imcleod-mtg is now known as imcleod
[18:42] <dmj_s76> infinity: In doing upgrade testing xenial->yakkety, the updater complains that it can't authenticate.  Is that expected currently?
=== buxy is now known as kalibot
=== kalibot is now known as buxy
[18:52] <slangasek> dmj_s76: certainly not; can you be more specific?
[18:53] <dmj_s76> So running do-release-upgrade -d
[18:54] <dmj_s76> gpg: BAD signature from "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>"
[18:54] <dmj_s76> Authentication Failed
[18:55] <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
=== buxy is now known as kalibot
=== kalibot is now known as buxy
[19:22] <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:41] <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:42] <chiluk> I understand you guys are knee deep in release time.
[20:01] <dmj_s76> slangasek: Actually checking into that
[20:03] <dmj_s76> slangasek: apt update works fine
=== ximion is now known as ximion-afk
[20:41] <tsimonq2> Who is responsible for yaboot nowadays?
[21:17] <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:18] <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
=== 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
[23:23] <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:27] <tsimonq2> slavanap: I would join #ubuntu-desktop if I were you :)
[23:28] <cjwatson> This isn't my field, but I think "nautilus extensions" would probably be good search terms here
[23:28] <tsimonq2> that too ^
[23:29] <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)
=== ximion is now known as ximion-afk
[23:34] <slavanap> tsimonq2, thanks for advice! :)
[23:35] <slavanap> cjwatson, got it! Thanks!
[23:39] <nacc> rbasak: took a while, but i think i've got the framework for upload/ tagging going now
[23:44] <nacc> rbasak: although something i've got is provoking a pygit2 segfault :)