=== maclin1 is now known as maclin [08:47] seb128: In regards to https://bugs.launchpad.net/ubuntu/+source/bittornado/+bug/1735346, http://torrent.ubuntu.com:6969/ [08:47] Launchpad bug 1735346 in bittornado (Ubuntu) "bittornado: Python3 port needed, or demotion to universe" [Undecided,New] [08:52] hey Unit193 [08:53] Unit193, I'm unsure what's your point there? [08:55] seb128: Mainly that bittornado is part of Ubuntu "infra", hence why it might be in main. Best guess at least. [08:56] Unit193, that might be an useful comment for the bug then, from my perspective it doesn't need to be on the iso, I don't know about IS use of it and what that means in support though [08:56] pretty sure they use it. [08:57] I know they do, page says as much. [08:57] the number of downloads/use is really low though, maybe they can close it :p [08:57] I never used the Py3 version of the tracker, by then I'd switched to opentracker (with udp support!), but I don't know if it does exactly what they want. [08:58] seb128: Not sure how much those numbers could be trusted, but having that tracker in there looks better than one that keeps changing and is used in all the latest pirated software. ;) [08:58] Anyway, FYI and all. [08:59] Unit193, thanks, that's an useful info, can you comment on the bug about that? [08:59] If I must. [09:00] (I wasn't sure that was warranted.) [09:03] Unit193, as you want, it might just help doko or others who care more than me about demoting python2 [09:12] (I still have py2 only stuff, thus have a vested interest in keeping it around. :P ) [09:19] (I posted a comment to the bug report.) [09:19] (thanks) [10:21] Unit193: universe should be good enough for keeping it around [10:21] mwhudson: do you want a promotion for golang-1.9? [10:22] I assume same bug scubscribers as golang-1.8 [10:22] I presume you are not addressing the Ubuntu torrent tracker with that statement, and in that case yes universe is (more or less) decent. [10:26] Unit193: but why not updating to the Python3 port? exchanging a non-maintained package with a slightly maintained package sounds better [10:26] doko: Regarding bittornado specifically? Yes I do use the py3 port, it's other stuff like Deluge and mini-dinstall which sadly aren't ready, or even started. [10:28] I tried porting launchpad-buildd to Python 3 over the weekend. It isn't quite workable on xenial (at least without some not entirely trivial backports), sadly. [10:28] Oh gah, https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bug/1099537 too. [10:28] Launchpad bug 1099537 in ubuntu-dev-tools (Ubuntu) "ubuntu-dev-scripts should be ported to Python 3" [Medium,In progress] [10:28] It's close, but twistd can't daemonise on Python 3 with twisted < 16.4.0. [10:29] is it worth thinking of a twisted backport, or update to 16.4 in xenial? [10:29] I suppose 'Convert Launchpad build system to pip' is still in progress. [10:29] or wait for bionic? [10:30] Unit193: I think the "in progress" might be out of date ;) [10:30] In what sense is it out of date? [10:30] doko: I quite agree. [10:30] https://code.launchpad.net/~cjwatson/launchpad/virtualenv-pip/+merge/331388 [10:30] doko: Yes, a backport might be an option [10:30] cjwatson: ubuntu-dev-tools port. [10:31] Oh, right, there were multiple referents for "in progress". [10:31] Indeed. [10:31] (Note that launchpad-buildd's use of Twisted is mostly independent from Launchpad's, and upgrading versions happens in entirely different ways.) [10:32] Speaking of, oh meh: https://github.com/twisted/twisted/pull/644 is still stalled. [10:32] (Though not entirely; at least the bits of launchpad-buildd that are run from the LP test suite need to work with the version in the LP tree.) [10:32] That sounds fun to maintain.. [10:33] Unit193: Also I think we might need to fix https://twistedmatrix.com/trac/ticket/8831 in order to be able to upgrade further than Twisted 16.5.0. [10:34] Unit193: Since https://twistedmatrix.com/trac/ticket/8079 will probably make ssh logins to codehosting and upload queues painfully slow otherwise. [10:34] Ouch. [10:35] Unit193: I have a branch that mostly upgrades Launchpad itself to Twisted 16.5.0 now though; still some test failures to shake out but it's looking close. [10:36] cjwatson: Well that's great then! The specific support I'm looking for isn't there yet, but in the meantime (apart from the chance of a slowdown), I'm sure that's good in and of itself, and makes future upgrades more possible, I'd wager. [10:37] Indeed, I think we're close to being past the hideous upgrade hump. [10:38] It's still all a bit "select exactly the right set of versions that works", but ... [10:39] Since versions before 16.5.0 fail to install into LP's pip tree due to some setup.py oddities [10:40] Ah, that's the catch then. OK. [10:41] Well, I guess versions somewhere between 13.0.0 and 15.5.0. Not exactly sure when it broke, but 16.5.0 fixed it. [11:27] learned a new word today "facile" === mhcerri_ is now known as mhcerri [15:35] was it easy to learn? [15:36] (sorry, I couldn't help it) [15:36] cyphermox, i forgot it already =) [15:36] ;) [15:37] cyphermox, but Colin's email was interesting to read. I doubt i know how to pronounce "facile" correct or if I will ever use it myself, or remember what it means next time I encounter it (if ever) [15:45] well to be fair it has several somewhat contradictory senses. I meant sense 4 on wiktionary [15:50] googling for "define facile" gave me the "ignoring the true complexities of an issue; superficial." definition, not sure which dictionaries/sources that uses. [16:19] xnox: close enough [16:20] (sometime in the last few years wiktionary got to the point where I'm happy to trust it as the dictionary of first resort, though.) [16:36] is there a way to resolve virtual-packages from apt? for example, linux-image-virtual, points to a specific package ? [16:38] rharper, but linux-image-virtual is not a virtual package, but a real one. [16:38] rharper, you can use dctrl-grep to inspect provides of the packages file? [16:40] oh, huh [16:41] I guess looking for the uname release string associated with the current version in the archive [16:41] like 4.4.0-103-generic [16:42] * rharper tries dctrl-grep [16:42] (it's spelled grep-dctrl) [16:42] thx [20:26] doko: yes pls [20:26] doko: golang-1.9-race-detector-runtime too [20:32] mwhudson: done [20:36] doko: ta [20:37] next step is demoting golang-1.8 i guess === alan_g is now known as alan_g|EOD [20:38] once golang-1.9 moves to the release pocket [20:38] (well immediate next step is waiting for britney) [20:38] yeah [20:50] rharper: some days i want to get business cards printed with "advanced grep-dctrl operator" on them [20:52] mwhudson: lol === rmk` is now known as rmk === StoneTable is now known as aisrael === dcmorton_ is now known as dcmorton === mbarnett_ is now known as mbarnett [22:07] RAOF: ping [22:08] jbicha: Yo! [22:08] You might be wondering when I'll get to colord-gtk? [22:09] yes, I didn't know if you were around or not :) [22:09] Yup, I'm around. [22:10] I'll stop poking around the Mir build system to get ninja working and do my colord gardening now instead :) [22:10] ooh, meson is nice once someone does the work to get it working [22:12] I like how it helps make SRU diffs easier to read by getting rid of the autotools noise [22:13] It's still a bit annoying to set up. [22:13] Particularly - colord does a two-stage indep/arch-dep build, which is not well supported in debhelper at the moment. [22:14] Because meson differentiates between “initial configuration” and “change configuration”. [22:16] jbicha: I always very carefully rebuilt apt stable updates with the same autotools version (well, in the target release) when they used autotools. glad I don't have to. not using meson yet, though, only cmake. [22:17] Our build system was also directory order dependent, so if the directory entries were in a different order, the .po files were completely noisy. [22:17] RAOF: yeah, a lot of complicated GNOME modules haven't been ported yet https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting [22:18] I expect apt to switch to meson within the next 2 years too [22:18] well, I hope. [22:19] CMake is ugly. === deltab_ is now known as deltab [22:30] * RAOF wonders whether meson will be ugly when it's mature enough to support all of the complicated GNOME modules… [22:31] RAOF: It will become the worst build system in existence eventually [22:32] I don't like it using python. [22:32] Adds more bootstrapping steps [22:32] there is some competition there [22:33] It's IMO better than autosetup, where everything is written in Tcl. [22:33] neomutt uses that [22:33] as does fossil, and jimtcl [22:33] e.g. scons [22:34] scons must be terrible [22:34] I remember some projects using it, but I have not seen any recently [22:34] i haven't used meson or autosetup or even cmake much [22:34] but scons is pretty bad [22:35] Oh, BTW: autosetup is just an autoconf replacement, it has no equivalent to libtool and automake [22:35] CMake really sucks because (1) the syntax is crap and (2) you have all these Find.cmake files [22:36] Don't use pkg-config, write your own find code ... [22:38] I don't understand at all why meson used if ... endif and not blocks like python. such a great chance to have readable code [22:39] or a ? b : c instead of b if a else c [22:40] That said, this is probably a terrible CMake script: https://anonscm.debian.org/cgit/apt/apt.git/tree/CMake/Documentation.cmake [22:41] It's APT's docbook / po4a support. [22:41] It's terrible. [22:42] gettext integration is not much better. === bluesabre_ is now known as bluesabre === ubott2 is now known as ubottu