| slangasek | tsimonq2: that looks fine. Also fine was the upstream statement that they are ok with us distributing the binaries | 01:57 |
|---|---|---|
| === nacc_ is now known as nacc | ||
| cpaelzer | hmm, any known hickup on the test machnies? I see "cati" on http://autopkgtest.ubuntu.com/running as "Running for 0g 16m" since yesterday | 09:54 |
| cpaelzer | test time dilation :-) | 09:54 |
| cpaelzer | and it affects i386, amd64 and ppc64 - so it isnot just one hung test vm | 09:56 |
| cpaelzer | OTOH armhf and s390x worked in ~24 minutes yesterday | 09:57 |
| cpaelzer | so it is not generally broken to be a hanging test | 09:57 |
| === LtWorf_ is now known as LtWorf | ||
| GunnarHj | Hi mvo, can you please revisit https://github.com/snapcore/snapd/pull/4723 ? | 12:59 |
| GunnarHj | I made the change we agreed on, but CI complained again. Can't see that the complaints are related to the proposed change. | 12:59 |
| GunnarHj | What now? | 12:59 |
| Laney | who's maintaining ddebs.u.c atm? Is there some known issue with syncing of some ddebs? I'm looking at https://launchpad.net/ubuntu/+source/clutter-1.0/1.26.2+dfsg-4/+build/14173188 - some of those don't show up at http://ddebs.ubuntu.com/pool/main/c/clutter-1.0/ | 13:02 |
| Laney | in fact most of the -4 ddebs aren't there | 13:02 |
| xnox | Laney, try bdmurray ? | 13:07 |
| Laney | cheers | 13:07 |
| Laney | I couldn't remember who owns that now | 13:07 |
| mvo | GunnarHj: in a meeting right now, but will look as soon as I can | 13:11 |
| cpaelzer | the cacti tests on autopkgtests are still dead (pretend to run for 15 minutes, but don#t move since a day) | 13:15 |
| cpaelzer | shouldn't there be a hard timeout at some point - if so does one know the timeout value? | 13:15 |
| cpaelzer | because atm I can't even restart them (test zombie apocalypse :-P ) | 13:16 |
| Laney | the running page was fake news, updated now | 13:17 |
| cpaelzer | thanks Laney, looking what is there now ... | 13:23 |
| cpaelzer | hmm the arches that appeared hanging before are now silently gone | 13:24 |
| cpaelzer | e.g. the test does not show up in http://autopkgtest.ubuntu.com/packages/cacti/bionic/amd64 | 13:24 |
| cpaelzer | neither as failed nor as passed | 13:25 |
| Laney | yeah give me a minute | 13:25 |
| cpaelzer | ah so this part also needs tim eto regen | 13:25 |
| cpaelzer | sure, will check in ~15 again | 13:25 |
| Laney | weird, our machine was restarted and that seems to have done something bad to the tests that were in progress at the time :( | 13:27 |
| cpaelzer | as long as we find a way out of the "something bad" hole all is fine | 13:27 |
| Laney | yeah it's fine | 13:27 |
| Laney | just requeue them | 13:27 |
| cpaelzer | need to wait until update_excuses relizes that they are gone | 13:28 |
| cpaelzer | Laney: or will that not happen and I should construct the requeue links manually? | 13:28 |
| Laney | I did it, don't worry | 13:29 |
| Laney | well just for net-snmp | 13:29 |
| Laney | to figure out which other ones are dangling it'll be easiest to wait for the queue to go down and see what's still in progress then | 13:29 |
| acheronuk | is anyone with knowledge of the latest ubiquity changes around? | 13:30 |
| acheronuk | https://bugs.launchpad.net/bugs/1752323 | 13:30 |
| ubottu | Launchpad bug 1752323 in ubiquity (Ubuntu) "Ubiquity crashes at startup on Kubuntu daily iso - 2018/02/28" [Critical,New] | 13:30 |
| cpaelzer | Laney: cluster-glue for net-snmp on amd64 and i386 are the same, did you requeue all of net-snmp or just the cacti tests? | 13:31 |
| GunnarHj | mvo: Ok, thanks. | 13:44 |
| === arges_ is now known as arges | ||
| === mhcerri is now known as mhcerri|lunch | ||
| bdmurray | Laney: juliank made some recent changes to the ddeb retriever so is more familiar with the code. | 15:30 |
| xevious | Is anyone else seeing this message while booting 18.04? "A start job is running for sys-subsystem-net-devices-multi-user.device (XXs / 1min 30s)" | 15:40 |
| xevious | For me, it waits the whole 1min 30s, then continues booting properly (networking works fine). | 15:41 |
| Laney | bdmurray: ok, but if there are any logs it might be good to look around that time to see if something shows up there | 15:43 |
| === nacc_ is now known as nacc | ||
| bdmurray | Laney: Noted | 15:46 |
| sunweaver | nacc: around? Quick request for feedback. I have a quite complex fix for the gosa mcrypt -> openssl transition, but I need more time than just today to upload a fix to unstable. | 15:49 |
| nacc | sunweaver: ack | 15:50 |
| sunweaver | Would you be willing to manually sync it over to bionic once uploaded (withing the next couple of days, if things go as planned). | 15:50 |
| nacc | sunweaver: i'll need to file a FFE for it, but I think that would be fine, given that the 'feature' is re-adding something that's present in prior releases | 15:50 |
| nacc | sunweaver: so ack :) | 15:50 |
| nacc | sunweaver: thanks for reaching out! | 15:50 |
| sunweaver | nacc: nice. I'll see to it with top prio. | 15:50 |
| === Elimin8r is now known as Elimin8er | ||
| === dcmorton_ is now known as dcmorton | ||
| === ]reed[ is now known as [reed] | ||
| === geofft_ is now known as geofft | ||
| === Cyrus is now known as Guest1156 | ||
| === rharper` is now known as rharper | ||
| nacc | mdeslaur: around? | 17:12 |
| nacc | mdeslaur: i'm noticing (well, others did in #ubuntu/#ubuntu+1) that ubuntu-support-status is reporting some weird packages in 'Unsupported' (on bionic, and a user reported on xenial) -- e.g., apt-file, expect, etc. | 17:13 |
| mdeslaur | nacc: apt-file and expect are both unsupported | 17:15 |
| nacc | mdeslaur: what does that mean in this context? | 17:18 |
| === Serge is now known as hallyn | ||
| === mhcerri|lunch is now known as mhcerri | ||
| nacc | mdeslaur: oh, no "Supported" field in packages? | 17:21 |
| nacc | mdeslaur: ... but why? :) | 17:21 |
| mdeslaur | nacc: it means the packages are in universe and nobody supports them | 17:24 |
| nacc | mdeslaur: so that's about package subscription? | 17:24 |
| nacc | mdeslaur: just trying to understand | 17:24 |
| nacc | (so i can answer better in #ubuntu/#ubuntu+1) | 17:24 |
| mdeslaur | nacc: you know the difference between main and universe, right? | 17:24 |
| nacc | mdeslaur: right | 17:24 |
| mdeslaur | main = canonical supports it, universe = community supports it | 17:25 |
| nacc | mdeslaur: so you're saying universe does not actually mean that, then | 17:25 |
| nacc | :) | 17:25 |
| mdeslaur | in universe, some packages have been assigned as being supported by specific community members, for example, packages that flavours have decided to support | 17:25 |
| mdeslaur | when a flavour asks for lts status, they sign up to support packages part of their package set | 17:26 |
| mdeslaur | and if nobody asks to support a package, it is "unsupported" | 17:26 |
| mdeslaur | which means nobody has commited to supporting it | 17:27 |
| nacc | ok, so "community supported" is actually more 'active' then just being in universe | 17:27 |
| mdeslaur | yes | 17:27 |
| nacc | mdeslaur: ok, that explains that, thanks | 17:27 |
| mdeslaur | once bionic comes out, some universe packages will have a 3-year supported firld | 17:27 |
| nacc | i think the community understood 'community supported' to mean 'is in universe' | 17:28 |
| mdeslaur | field | 17:28 |
| nacc | so i'll correct that :) | 17:28 |
| mdeslaur | unfortunately, nobody has committed to supporting all of universe yet ;) | 17:28 |
| alkisg | Wouldn't it be better to list the debian maintainers there? | 17:32 |
| mdeslaur | in what way are debian maintainers supporting ubuntu packages? | 17:32 |
| alkisg | (assuming there's no ubuntu .diff) | 17:32 |
| mdeslaur | they aren't releasing security updates for ubuntu, or fixing bugs | 17:33 |
| alkisg | Ubuntu bug => report in launchpad, debian bug => report in debian, upstream bug => report upstream | 17:33 |
| alkisg | As as users, shouldn't I get to know that there are those 3 levels of support here? | 17:33 |
| alkisg | *there | 17:33 |
| alkisg | *as a user... | 17:33 |
| TJ- | The misunderstanding is because the word "support" is used in more than context; most users understand it as being able to get help whereas as for packages a better word would be "maintained" | 17:33 |
| TJ- | s/more than context/more than ONE context/ | 17:34 |
| mdeslaur | alkisg: while packages originally come from debian, once ubuntu is released, updates no longer trickle down | 17:35 |
| alkisg | mdeslaur: eh, there are several cases where a new debian release gets SRU'ed or microupdated to Ubuntu after release | 17:35 |
| alkisg | But the main point is "I have this bug report that I want to file, where would I file it, how to contact the person that wrote that package that I'm using, is anyone maintaining it..." not so much as "how can canonical support me" | 17:36 |
| mdeslaur | that would be "always in ubuntu" | 17:36 |
| alkisg | So personally I'd really like it if it was clearer for the users that there are those 3 levels of support; I'm seeing even long time users that don't realize that | 17:37 |
| mdeslaur | Well, I disagree with the three levels | 17:38 |
| mdeslaur | but meh | 17:38 |
| xnox | alkisg, canonical customers use the Ubuntu Advantage to file tickets typically. And that has 3 leves of support - Essential, Standard, and Advanced ;-) | 17:41 |
| alkisg | xnox: yeah, it's like trying to fit the canonical marketing into .deb fields, it doesn't fit so well there :) | 17:42 |
| alkisg | Upstream code, debian packaging, ubuntu diff... 3 teams writing code, and it's best to file bug reports to the team that wrote the exact line that causes each issue... but sure, there are many ways to view it, that's just mho | 17:42 |
| xnox | alkisg, there is no way to generalise things, as it very much depends on the bugs and issues at hand. Most of the time, it all boils down to specific bugs/problems/issues encountered. And at times, the fixes may be cherrypicked in one package, multiple package, other packages, and/or fixes and solutions created from scratch. | 17:43 |
| xnox | alkisg, no, it is not best to file a report with a specific team, for a shortest time to fix. | 17:43 |
| xnox | alkisg, as often times, independant things work correctly by themsevles, yet fail to integrate, with no fault of any of the individual teams. | 17:43 |
| xnox | alkisg, ubuntu bugs, should go to ubuntu first. always. | 17:44 |
| mdeslaur | if you want it fixed in ubuntu, it needs to be filed in ubuntu | 17:44 |
| alkisg | Let's take a package in universe for example. Noone maintains it in ubuntu. Why would we want a bug report in launchpad for that, instead of redirecting users to debian or upstream? | 17:44 |
| xnox | then go through Ubuntu bug triange, then find the fix, and dig deeper. | 17:44 |
| xnox | alkisg, because ubuntu systems, are different enough, to warrant different behaviour, of the same source code. | 17:45 |
| alkisg | I've seen thousands of bug reports in launchpad like that, that just then make users not want to file bugs anymore | 17:45 |
| mdeslaur | alkisg: what good is redirecting a user to debian if the package in ubuntu doesn't match the package in debian? | 17:45 |
| xnox | alkisg, we have differt ISA levels on all architectures, vs debian. | 17:45 |
| xnox | alkisg, different kernel, toolchain, libc, qt, gtk, etc. | 17:45 |
| alkisg | mdeslaur: agreed. But what if it's in universe, with no ubuntu .diff, and noone maintains it in ubuntu, etc etc? | 17:45 |
| alkisg | Wouldn't it be better for the users to at least know that they may get support either in debian, if they reproduce it there, or upstream in many cases? | 17:46 |
| xnox | alkisg, we do maintain universe, we do fix FTBFS bugs, we do upload srus for universe. Note, everything in main, at one point was in universe! | 17:46 |
| alkisg | Now many users don't know that | 17:46 |
| mdeslaur | alkisg: nobody in debian is going to maintain the package in ubuntu either...if you have 1.2.7-1 in ubuntu and debian is at 1.3.6, good luck getting something useful out of filing a bug with debian | 17:46 |
| xnox | alkisg, it's like Mint users filing bugs in launchpad, instead of Mint -> most of the time i really cannot help them at all. | 17:46 |
| mdeslaur | this is exactly what "supported" means...someone has committed to making sure the bug gets looked at and fixed | 17:47 |
| xnox | alkisg, i think you are mistaken on the level of good will of people. And a valid bug, is a valid bug. | 17:47 |
| xnox | most bugs, are valid across many versions of upstream software. | 17:47 |
| xnox | it's very "lucky" to hit a bug, which has already been fixed elsewhere. | 17:47 |
| alkisg | Anyways I think we said our points of view; not sure what I could add (or you could add) to change each other's minds... we all have enough experience with bugs to have made our own minds up | 17:49 |
| alkisg | In the past, I used to start filing bug reports in ubuntu first, that was very disappointing in many cases | 17:49 |
| alkisg | Currently, I follow that 3-levels-of-support method, and it's much more effective for me | 17:50 |
| nacc | xnox: i think the contentious point (to me) is "< xnox> alkisg, we do maintain universe" | 17:50 |
| nacc | xnox: except there is some percentage of universe that is 'unsupported' (which would imply unmaintained to me) | 17:50 |
| mdeslaur | we don't maintain universe, we will sponsor and help anyone who wants to fix something in universe | 17:50 |
| mdeslaur | that's not the same | 17:50 |
| xnox | nacc, the amount of work i put into package maintainance in debian, and in ubuntu, and in universe, is a bit insulting to say unmaintained. | 17:50 |
| nacc | mdeslaur: perhaps there should be help text in ubuntu-suppor-tstatus :) | 17:50 |
| mdeslaur | nacc: file a bug! ;) | 17:51 |
| nacc | xnox: i agree, i'm going by what i would read if i saw the u-s-s output | 17:51 |
| nacc | mdeslaur: ack :) | 17:51 |
| xnox | nacc, alkisg - mdeslaur's perspective is from an Ubuntu Security point of view, and there is no guarantee that CVE fixes are shipped for packages in universe. | 17:51 |
| nacc | mdeslaur: i think if the terms were well-defined, it would not be an issue, so that's probably teh right approach | 17:51 |
| mdeslaur | nacc: file it in debian first, let's see how that goes ;) | 17:51 |
| nacc | lol | 17:51 |
| xnox | but from the point of universe, as during development, it is maintained a lot. by us, where us, are people in the Ubuntu Foundations team | 17:51 |
| nacc | mdeslaur: i'm really not trying to blame you. i was suprising to see how many packages on my system were 'unsupported' | 17:52 |
| nacc | when they are 'maintained' as xnox said | 17:52 |
| xnox | autopkgtests fixes, ftbfs fixes, abi/library transitons, etc. | 17:52 |
| nacc | 'unsupported' in such a tool, to me, reads like 'where the hell did this package come from' | 17:52 |
| mdeslaur | nacc: "supported by nobody" perhaps? ;) | 17:52 |
| mdeslaur | I'm not sure what a good term is | 17:53 |
| xnox | nacc, what is 'unsupported'? all packages in ubuntu are supported, but they have different timeframes. | 17:53 |
| mdeslaur | for something that nobody has committed to support | 17:53 |
| nacc | xnox: exactly | 17:53 |
| alkisg | Not supported by Ubuntu | 17:53 |
| nacc | xnox: it's the ubuntu-support-status output, though :) | 17:53 |
| mdeslaur | xnox: "supported for 0 days" | 17:53 |
| mdeslaur | xnox: let me know which universe packages you support so I can send you the CVEs | 17:54 |
| xnox | nacc, i'm not sure what you expect from that tool. that tool, tries to list things that get HWE, security, and regular SRUs only, in stable releases. | 17:54 |
| xnox | for the purpose of commercial support. | 17:55 |
| nacc | xnox: it doesn't say that anywhere | 17:55 |
| mdeslaur | http://people.canonical.com/~ubuntu-security/cve/universe.html | 17:55 |
| nacc | xnox: and it doesn't say canonical-support-status | 17:55 |
| nacc | which perhaps it should | 17:55 |
| xnox | nacc, it does say which bits is canonical supported, and which are community supported. | 17:55 |
| xnox | nacc, because official flavours, have community support: some sign up for 3y, some for 5y. | 17:56 |
| nacc | xnox: i mean it does not say "I try to list things that get HWE, security and regular SRUs for the pruposes of commercial support" | 17:56 |
| xnox | nacc, e.g. kubuntu is 5y community supported package. | 17:56 |
| nacc | which would be a canonical thing (I assume) | 17:56 |
| nacc | xnox: i understand all that :) | 17:56 |
| xnox | nacc, please read the output of ubuntu-support-status | 17:56 |
| xnox | nacc, it does state canonical, community, nobody designated. very clearly. with timeframes. | 17:56 |
| nacc | https://paste.ubuntu.com/p/WwSdscnwfd/ | 17:57 |
| nacc | xnox: yes, i'm not arguing with that | 17:57 |
| nacc | xnox: it does not define what 'unsupported' is | 17:57 |
| * xnox even has packages that are "that can not/no-longer be downloaded" | 17:57 | |
| xnox | nacc, but for _all_ of these, bugs go to launchpad. and _all_ of these is still ubuntu. | 17:57 |
| mdeslaur | it means "nobody has committed to support" | 17:57 |
| nacc | mdeslaur: right, i know that now :) | 17:57 |
| mdeslaur | is there a better synonym? | 17:57 |
| xnox | not that no support will be provided | 17:57 |
| nacc | xnox: i don't see how any user would know that | 17:57 |
| xnox | because opportunistically, there is support provided. | 17:57 |
| * xnox spots mistakes in ubuntu-support-status in bionic | 17:58 | |
| mdeslaur | xnox: good, go fix the seeds ;) | 17:59 |
| nacc | xnox: right, i think your distinction can be expressed by the tool | 17:59 |
| nacc | xnox: my hope is that users can run this on their system and we can quickly see what they have installed from 3rd party | 17:59 |
| nacc | xnox: right now, the unsupported part makes that harder (afaict) | 17:59 |
| xnox | nacc, please open a bug, on launchpad, against update-manager package ;-) | 18:00 |
| mdeslaur | If someone has a better term than "unsupported" that clearly informs users to not expect support, I'm all ears | 18:00 |
| xnox | nacc, the distinction of source of instalation, would be nice. cause e.g. google-chrome package installed form dl.google.com repository is clearly supported .... (by Google) | 18:01 |
| alkisg | It would indeed be a lot clearer if the components were "main, 3years-community-sup, 5years-community-sup, universe" :D | 18:01 |
| xnox | nacc, and universe from ubuntu; is different from a random PPA | 18:01 |
| nacc | xnox: right | 18:01 |
| mdeslaur | please don't pretend universe is supported in any way | 18:01 |
| nacc | lol | 18:02 |
| nacc | xnox: mdeslaur: i feel like you're saying different things re: universe | 18:02 |
| nacc | which is why i think the tool needs to be explicit about what it means :) | 18:02 |
| mdeslaur | sorry, I mean the part of universe nobody has commited to supporting | 18:02 |
| mdeslaur | ie: not community | 18:02 |
| xnox | nacc, alkisg - and what you imply is not "support" either. | 18:03 |
| xnox | or ask for. | 18:03 |
| nacc | xnox: what did I imply? | 18:03 |
| xnox | nacc, it seems like you are saying "it appears as if I installed too many packages, not from ubuntu repositories" which has nothing to do with weather there is a team that committed to provide timely critical SRUs & security patches. It seems to me that for you support is "there is a place to file bugs, which are looked at by people, and fixed eventually, via ongoing upgrades" -> which i call maintainance. | 18:04 |
| nacc | xnox: if the tool is *only* about security updates | 18:04 |
| nacc | thenit should be named something else | 18:05 |
| * mdeslaur considers deleting the tool completely | 18:05 | |
| nacc | mdeslaur: +1 :) | 18:05 |
| xnox | nacc, break your concerns down into smallest concern possible, phrase it as simple as possible, and open a bug report. | 18:05 |
| TJ- | There's a relatively simple change to the tool which could clarify things enormounsly. When using --show-unsupprted and lumping all Ubuntu and 3rd party packages in one list, separate those out with different headers so instead of "Unsupported:" there is "Unsupported (Ubuntu universe/multiverse):" and "Unsupported (Third party installs):" | 18:05 |
| nacc | xnox: yep | 18:05 |
| xnox | mdeslaur, people still look at Supported: field in the package archive. | 18:05 |
| mdeslaur | xnox: too bad it's wrong for every release except bionic | 18:06 |
| mdeslaur | xnox: the whole point of the ubuntu-support-status sru was to stop relying on it for stable releases | 18:06 |
| xnox | mdeslaur, we fixed up xenial-updates! | 18:06 |
| mdeslaur | well :P | 18:06 |
| mdeslaur | let's just make sure it's going to be accurate in bionic | 18:07 |
| mdeslaur | TJ-, nacc: I think separating out third party installs is a good idea | 18:07 |
| xnox | TJ-, grouping by Apt-Sources is hard, due to lack of description, and one can be using a random self-hosted ubuntu mirror. I guess we could group by the overriden maitnainer. | 18:07 |
| nacc | mdeslaur: LP: #1752380, feel free to reword | 18:08 |
| ubottu | Launchpad bug 1752380 in update-manager (Ubuntu) "ubuntu-support-status: emit source of packages" [Undecided,New] https://launchpad.net/bugs/1752380 | 18:08 |
| TJ- | xnox: for Ubuntu packages can't we rely on the apt /lists/ files ? | 18:08 |
| xnox | however, grouping the output by Apt-Sources will be a massive step up. | 18:08 |
| xnox | TJ-, ubuntu-support-status goes via api, so it pulls things as seen by e.g. $ apt show ubuntu-dev-tools | 18:09 |
| xnox | that has: | 18:09 |
| xnox | APT-Manual-Installed: yes | 18:09 |
| xnox | APT-Sources: http://gb.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages | 18:09 |
| xnox | but | 18:09 |
| mdeslaur | I doubt we'll have enough information to be able to do it with apt, but it would definitely be nice | 18:09 |
| xnox | TJ-, deb http://gaosu.rave.org/ubuntu/ is also ubuntu..... | 18:10 |
| TJ- | can we via API get the same info that "apt list --installed" provides? | 18:10 |
| nacc | TJ-: LP: #1752379, if you want to help me flesh that out | 18:10 |
| ubottu | Launchpad bug 1752379 in update-manager (Ubuntu) "ubuntu-support-status could more clearly define unsupported" [Undecided,New] https://launchpad.net/bugs/1752379 | 18:10 |
| mdeslaur | xnox: what about the Origin tag, do people put Ubuntu in their third-party repos? | 18:10 |
| * xnox doesn't know about origin of Origin | 18:10 | |
| TJ- | nacc: xnox I'll do some hacking on the source see what is possible | 18:11 |
| xnox | at least google-chrome-stable does not have Origin, but does have Apt-Sources | 18:11 |
| xnox | maybe we can group things by origin. | 18:11 |
| mdeslaur | "Maintained by nobody for 5 y" | 18:11 |
| * xnox giggles | 18:12 | |
| nacc | mdeslaur: xnox: you bring up a good point, support vs. maintain | 18:13 |
| nacc | i think as ubuntu developers, etc. the difference is clear, but for regular users it might not be | 18:13 |
| TJ- | I'm getting sick of LP! Someone tell me where/how to fetch the latest code for update-manager! | 18:13 |
| nacc | TJ-: `pull-lp-source update-manager` | 18:13 |
| mdeslaur | I'm not sure I know the difference between support and maintain myself | 18:14 |
| cjwatson | or for the latest upstream, 'bzr branch lp:update-manager' | 18:14 |
| xnox | things that are not maintained, are removed from the archive, and then upon upgrades it is listed as "packages no longer available, would you like to remove them?" | 18:14 |
| TJ- | To me "maintain' infers bugs may be fixed whereas "support" means someone might help me use/configure the package | 18:14 |
| xnox | for example, upstart is supported in xenial; but no longer maintained, and has been removed from ubuntu. | 18:15 |
| nacc | TJ-: --^ but i think that contradicts your definition | 18:15 |
| nacc | because id on't think anyone will a user configure/use upstart on xenial :) | 18:15 |
| nacc | it's there :) | 18:15 |
| mdeslaur | so we should never use "support" then | 18:15 |
| nacc | mdeslaur: i wonder if that's really the underlying issue :) | 18:16 |
| xnox | TJ-, maintain -> bugs will be fixed in the devel series, and if suitable might be eligible for SRU/Security/Backport (support), the "support" to use/configure is typically called "end-user support", rather than the L3 support which what the "supported" status implies. | 18:17 |
| nacc | xnox: so u-s-s is only relevant to canonical customers? | 18:17 |
| nacc | (trying to narrow down what L3 support is) | 18:18 |
| TJ- | nacc: cjwatson: thanks :) so which of the 3 methods is the 'canonical' (not Canonical!) one to use between pull-lp-source, bzr branch lp:update-manager and git clone https://git.launchpad.net/~usd-import-team/ubuntu/+source/update-manager ?? | 18:18 |
| cjwatson | I reckon that never trying to reduce any of these complex concepts to a single misunderstandable word would be a good idea | 18:18 |
| xnox | TJ-, e.g. canonical provides very little end-user support. Yes the toolchain is in main, but we provide very little direct end user support, as to why ubuntu gcc doesn't compile sombodies code..... | 18:18 |
| TJ- | nacc: I know, rename the tool to canonical-support-status :D | 18:18 |
| mdeslaur | TJ-: but we want to know which packages are community-supported too | 18:19 |
| xnox | TJ-, but that's still confusing, if you are after "support" to use/configure a thing =) | 18:19 |
| cjwatson | TJ-: pull-lp-source gets you the most recent version in the Ubuntu archive; bzr branch lp:update-manager gets you what's under development upstream. Neither of those is more canonical than the other, since it depends what you're trying to do | 18:19 |
| TJ- | mdeslaur: :P that's a little 'c' not a big 'C' | 18:19 |
| mdeslaur | lol | 18:19 |
| mdeslaur | this conversation wasn't confusing enough ;) | 18:19 |
| cjwatson | TJ-: the git clone is an under-development method to fill the same slot as pull-lp-source in a more convenient/powerful/etc. way | 18:19 |
| nacc | TJ-: and the git repo will eventually (hopefully) supplant the `pull-lp-source` option | 18:19 |
| * TJ- whistles innocently | 18:19 | |
| TJ- | cjwatson: aha, because I do prefer git... so I'm safe to use that (in this case) ? | 18:20 |
| nacc | TJ-: i'd make sure it's up to date (I'd need to check) | 18:20 |
| nacc | it *should* be, but we're under some flux right now | 18:20 |
| cjwatson | TJ-: like I say it depends what you're doing. If you intend to contribute code somewhere, you should always start from the intended target of your contributions | 18:20 |
| TJ- | nacc: It's OK I'll compare the two trees after using both methods | 18:20 |
| xnox | TJ-, i believe usd-import-team is "pull-lp-source done with git" and should match latest in-archive version; but it's not a suitable base for e.g. merge proposal into the devel series. | 18:21 |
| cjwatson | TJ-: (and IMO it's generally best to contribute code as far upstream as possible, all other things being equal) | 18:21 |
| TJ- | cjwatson: right, which is why I was trying to figure out which one to use... generally I prefer working on the development master branch and then backport/cherry-pick | 18:21 |
| cjwatson | TJ-: with that extra piece of information, I'd recommend bzr branch lp:update-manager | 18:22 |
| * xnox shakes fist "native" package format should not have ever existed | 18:22 | |
| TJ- | xnox: right ... as if figuring out the meaning of 'support' wasn't painful enough, now I have to figure out 'canonical method' :D | 18:22 |
| TJ- | cjwatson: thanks | 18:22 |
| TJ- | cjwatson: I can use the git-bzr thing to do that too, so I'm happy | 18:23 |
| xnox | TJ-, thinking about it, there is a lot more end-user support on how to use/configure things; including majority of things in universe. As there are a tonne of guides and blogs and forums on the interent telling people how to use this or that on ubuntu. | 18:23 |
| nacc | xnox: right, but 'random forum post' would never be considered Ubuntu support | 18:24 |
| TJ- | In the context of IRC then in #ubuntu for example 'support' means any package in the archives | 18:25 |
| mdeslaur | perhaps the tool should say what support means... "Security updates and important bug fixes" or something | 18:27 |
| TJ- | mdeslaur: indeed, I think it writing footnotes would be great idea | 18:27 |
| nacc | mdeslaur: yeah that's what i initially was writing in LP #1752379 | 18:27 |
| ubottu | Launchpad bug 1752379 in update-manager (Ubuntu) "ubuntu-support-status could more clearly define unsupported" [Undecided,New] https://launchpad.net/bugs/1752379 | 18:27 |
| nacc | mdeslaur: i can file a third bug if that's appropriate | 18:27 |
| nacc | or can just amend that one to request defining all the relatively subjective terms | 18:28 |
| mdeslaur | I think adding to that one is fine | 18:29 |
| nacc | mdeslaur: bug amended | 18:29 |
| TJ- | to save duplication, if no one objects, I'll work through these? | 18:29 |
| mdeslaur | no objection from me | 18:30 |
| nacc | TJ-: +1 | 18:30 |
| mdeslaur | as long as the resulting output allows someone to know which packages they shouldn't count on having security updates for, I'm ok | 18:30 |
| TJ- | I may be back with questions especially regarding the API if I get lost | 18:30 |
| nacc | mdeslaur: ack | 18:31 |
| nacc | xnox: totally separate question, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846219 is why fusionforge is stuck in b-p. It was filed over a year ago and no response; does that imply fusionforge is abandoned in Debian? | 18:31 |
| ubottu | Debian bug 846219 in src:fusionforge "Missing runtime dependencies (former libarc-php, libgraphite-php and php-http)" [Grave,Open] | 18:31 |
| TJ- | mdeslaur: I'd like to see something like "Security updates for X years" | 18:31 |
| nacc | xnox: i woudl ask in the bug, but not sure if the debian maintainer would find it offensive to be asked "did you abandon this?" | 18:33 |
| xnox | nacc, if you at all follow recent news about alioth shutdown, and move to gitlab instance salsa..... you would know that yes, fusionforge has been abandoned for years now =) | 18:43 |
| xnox | alioth (fusionforge) is dead; long live salsa (gitlab) | 18:44 |
| xnox | https://salsa.debian.org/public | 18:44 |
| nacc | xnox: fusionforge is still in debian and ubuntu | 18:45 |
| nacc | xnox: should we delete it? | 18:45 |
| xnox | nacc, probably, yeah. | 18:47 |
| nacc | xnox: ok | 18:48 |
| nacc | xnox: because it sounds like it's both unsupported and unmaintained :) | 18:48 |
| xnox | nacc, it needs to be unshipped | 18:50 |
| Odd_Bloke | Canonically unsupported and unmaintained? | 18:50 |
| * Odd_Bloke runs. | 18:50 | |
| nacc | xnox: ack | 18:52 |
| nacc | Odd_Bloke: :) | 18:52 |
| seb128 | jbicha, doh, the clutter autopkg test now fail on | 20:32 |
| seb128 | Unpacking fonts-ubuntu-console (0.83-1) ... | 20:32 |
| seb128 | dpkg: error processing archive /var/cache/apt/archives/fonts-ubuntu-console_0.83-1_all.deb (--unpack): | 20:32 |
| seb128 | trying to overwrite '/usr/share/consolefonts/UbuntuMono-B-8x16.psf', which is also in package fonts-ubuntu-font-family-console 1:0.83-0ubuntu2 | 20:32 |
| seb128 | jbicha, that transition is not meant to clear before ff it seems :/ | 20:33 |
| jbicha | seb128: sorry, fix was just uploaded to bionic-proposed (missing breaks/replaces) | 20:33 |
| seb128 | jbicha, ok, I guess we need to retry things when it's published then | 20:33 |
| seb128 | jbicha, thx | 20:33 |
| sladen | ta | 20:37 |
| slangasek | seb128: all autopkgtests are busted right now, I'll be batch-retrying | 20:41 |
| seb128 | slangasek, thanks | 20:41 |
| bdmurray | jbicha: is bug 1751546 something you could take a look at? | 20:55 |
| ubottu | bug 1751546 in tasksel (Ubuntu) "the net installer doesn't install gnome-vanilla" [High,Confirmed] https://launchpad.net/bugs/1751546 | 20:55 |
| jbicha | bdmurray: not this week, but feel free to remind me later | 20:58 |
| bdmurray | jbicha: would assigning it to you be a good reminder or ...? | 20:58 |
| jbicha | no, I haven't really used the LP assignment feature | 20:59 |
| === lyarwood_ is now known as lyarwood | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!