[00:02] <psusi> I'm guessing it is because gnupg-agent depends on pinentry-curses | pinentry
[00:03] <psusi> and apt evaluated that first and so selected the curses version, which then satisfied gnome-keyring
[00:07] <cjwatson> in xenial it just outright Depends: pinentry-gnome3
=== nudtrobert1 is now known as nudtrobert
[12:50] <Guest84389> Hi, is there a reason that starting from libpython3.4-dev (3.4.3) there is no libdir variable set in the pkg-config?
[14:10] <ari-tczew> cyphermox: I'm just looking on changes happened in network-manager. I noticed that in merge version 0.9.10-4 you got "Don't have network-manager Depend on adduser.", but in the next merge 1.0.4 such change doesn't exist anymore. Could you check that one?
[16:07] <__marco> Hi where should I ask for a package removal?
[16:09] <sladen> __marco: launchpad
[16:09] <sladen> __marco: but it's probably easier if you say what package it might be ;-)
[16:09] <__marco> virtualbricks
[16:09] <__marco> http://packages.ubuntu.com/wily/virtualbricks
[16:10] <__marco> That version is so old that could be considerate obsolete
[16:11] <sladen> https://packages.debian.org/jessie/virtualbricks  seems to the same version as in Debian ?
[16:11] <sladen> (both 0.6.352-1)
[16:11] <sladen> __marco: what's the plan for Debian?
[16:11] <__marco> yes, but a new version should be uploaded soon
[16:12] <__marco> I contacted the Debian maintainer and he will upload the new version as soon as he has time
[16:12] <sladen> so to avoid breaking people's systems, and save work overall, would it make more sense to wait a couple of weeks and have it synced from Debian
[16:13] <__marco> will the versions in willy and xenial updated as well?
[16:14] <__marco> I mean, now that willy is releases, will a new version of a package accepted?
[16:16] <__marco> otherwise waiting few weeks is not a problem at all
[16:20] <sladen> __marco: it will get auto-synced to Xenial
[16:21] <sladen> __marco: if there is a significant-enough reason (major bugs/non-functionality) then one can apply for an SRU (Stable Release-Update) to get it into wily
[16:22] <sladen> __marco: there are occasional removals, but it's got to be a pretty strong reason.  For example bittorrent after the protocol changes and the other clients became /useless/
[16:22] <sladen> __marco: being old on its own it's really reason enough, if it still works
[16:23] <sladen> __marco: because users, by choosing a release, rather than the development pre-release are after stability
[16:26] <xnox> cjwatson: sigh =)
[16:26]  * xnox wishes that e.g. with dgit support these things can be auto-detected and auto-generated.....
[16:27] <__marco> sladen: that version is full of bugs :). It never worked really and only cause of trouble to our users.
[16:28] <infinity> So backport the bugfixes.
[16:29] <__marco> The new version is the bugfix. It is (mostly) compatible with the old one
[16:29] <infinity> Yeah.  That right there isn't suitable for an SRU.
[16:30] <infinity> We don't take new versions just to fix bugs in *stable* releases.  Stable means "stable interfaces and behaviour", not "free of bugs".
[16:30] <infinity> So, to fix bugs in a stable, you need to fix the bugs, not pull in a whole new version willy-nilly.
[16:31] <__marco> a version is just a number. Pull the changes and you get the same interface and the same behaviour without the bugs
[16:34] <infinity> You literally just used the evasive phase "(mostly) compatible".
[16:34] <infinity> So, it's not "just a number".
[16:34] <infinity> s/phase/phrase/
[16:38] <__marco> we had few compatibility issues that we fixed. The problem is that the users of the old version are so few that our tests weren't enough. But will continue to work to improve that aspect
[16:38] <__marco> a non-compatibility is a bug
[16:42] <__marco> The major problem with that version in ubuntu is that "irritate" our users. Most of them never seen linux and a terminal. They do not understand what a repository is and how to install a specific version of a package
[16:43] <__marco> when they do `apt-get install virtualbrick` and "it does not work, the program hangs", it is our fault for them
[16:43] <infinity> So submit patches to fix the hangs?
[16:43] <__marco> it does not matter if they just installed the wrong version
[16:44] <infinity> We do this sort of thing all the time, there's no reason you need hundreds of commits to fix a few bugs.
[16:45] <__marco> because the whole structure of the program was fragile and, if you will, I am such a good programmer to fix all of those problem in few commits
[16:47] <__marco> I am sorry but I will try to backport the new version to willy and, if it will not work, I will try to remove it
[17:05] <sladen> __marco: "whole structure of the program was fragile", this is why backport small eyeball-able fixes, instead of "just taking the new release"
[17:06] <sladen> __marco: patches to fix bugs fully greeted with enthusiasm (both here, and in Debian---file in Launchpad/debbugs with minimal diff and precisely attributable to the bug it fixes)
[17:07] <sladen> __marco: the crucial difference is bug fix vs. new features
[17:08] <sladen> __marco: yes, it's tempting to put new good stuff in, but that doesn't keep the bug fixes trackable, nor achieve interface/library stability---which is the reason people choose "a release" (even if they don't know it)
[17:15] <__marco> So looks really simple I will more than happy to do it if only I could. The cause of such hangs was a wrong use of threads. Many of commits are the attempt to fix it. I looks to work, until the program hanged one time more
[17:17] <__marco> And fix threads problems is not so easy. "That threads should do something and use a library which is not threadsafe but have to use it to achieve that"
[17:17] <__marco> so a new core was born which does not use threads. It this a feature o a bug fix?
[17:19] <__marco> And all the refactoring, is splitting a function in two a feature or a bug fix?
[17:20] <__marco> I am not trying to teach you your work nor trying to be an asshole. Just we think that that version should be not used by anyone. And not just because we want so.
[17:22] <__marco> We never thought that it could be part of Ubuntu. That was our main mistake
[17:22] <__marco> Because, I could prove it, it will not work in Ubuntu
[17:25] <__marco> s/will/does/
[17:29] <__marco> but anyway, I want to thank you to bear with me and show me such a big problem
[17:29] <__marco> :)
=== dkessel_ is now known as dkessel
[18:25] <cyphermox> ari-tczew: IIRC it's unimportant, it's just that adduser gets used in debian to add the user to netdev, which we don't use in ubuntu. so I suspect it was just forgotten
=== \b is now known as benonsoftware
[20:46] <ari-tczew> morphis: are you going to merge network-manager? I've partially done