[05:27] bluesabre: Yeah I use gpg-agent --daemon --write-env-file "${HOME}/.gnupg/gpg-agent-info" somewhere else. [12:54] bluesabre, flocculant: ? [12:57] kryten, you still around? [12:57] Yes. [12:57] you running xenial? [12:58] Nope. [12:58] bah [13:01] bluesabre, when you set --> APT::Periodic::Unattended-Upgrade "!"; <-- in /etc/apt-/apt.conf.d/20auto-ugprades, the "When there are security updates" dropdown box gets grayed out in Software & Updates -> tab Updates [13:01] bluesabre, the stupid thing here is that it doesn't show any value there, so the user can't confirm they are installed daily unless they know to look in the aforementioned file [13:03] ahhh, bug 1018367 [13:03] bug 1018367 in unattended-upgrades (Ubuntu) "Unable to remove unattended-upgrades" [Undecided,Confirmed] https://launchpad.net/bugs/1018367 [13:03] not old or anything [13:04] ohh, a very good comment there "Is there a massively effective corporate (MS?) sabotage unit working inseide the core of linux community?" [13:07] and yes, there it is, reported by flocculant in bug 1554099 [13:07] bug 1554099 in software-properties (Ubuntu Xenial) "Changing what action for security updates unusable" [High,Confirmed] https://launchpad.net/bugs/1554099 [13:07] :D [13:39] slickymaster, do we want to keep https://wiki.ubuntu.com/Xubuntu/Documentation ? [15:26] knome: am now - and I see you found stuff [15:27] yep [15:27] that was it [15:27] :) === rw is now known as dax [15:54] wow, i would have thought the tons of package installation errors on an upgrade to be gone at this time in the cycle.... :/ [15:55] dkessel: nope [15:55] when it's not broken I'll mail the list about testing it again :) [15:55] ok, reverting that VM then.... [15:55] anyone trying to upgrade 14.04 to 16.04 is in for a bumpy ride :p [15:56] last I checked 15.10 to 16.04 worked [16:04] well i just tried 15.10 to 16.04 ;) [16:07] dkessel: it failed? [16:08] 2 weeks ago 15.10 to 16.04 was working [16:10] flocculant: yeah, i got all those systemd, init, xubuntu-desktop, etc. installation errors [16:11] mmm [16:11] davmor2: were you getting upgrade fails on 15.10 to xenial ? [16:12] didn't get that far but I would imagine it would hit a similar issue [16:12] mmm [16:12] 2 weeks ago it was working - today not it seems [16:13] at least a vanilla vm install did [16:13] flocculant: yeah but that was the same with 14.04 it was working a week or two before feature freeze and then died horribly afterward [16:14] davmor2: I've not got 14.04 to upgrade ever [16:14] though it's not something we test really regularly [16:14] indeed [16:15] well - that's a stupid comment ... can only do it once every 2 years anyway lol [16:15] :D [16:15] dkessel: can you get at logs? [16:16] if not I'll do something - would at least like to know where it fails and if it is the same [16:16] flocculant: and between 10.06 and 12.04 and 14.04 there weren't as many lib changes and abi breaks as there are from 14.04 to 16.04 either [16:16] yea [16:17] gcc, bluez, amd gfx stack, nm when that lands and the list goes on [16:18] he he he [16:19] flocculant: logs are gone... just rolled back the vm [16:19] i need to make a bootable .iso of my usb drive live session. dd worked fine in ubuntu, but not in xubuntu. how can i do this? [16:19] the price of progress - grey hair or if really unlucky bald head [16:19] xubuntu84w: #xubuntu is the support channel [16:19] bbut it's for rolling a distribution [16:20] but if it doesn't work in xubuntu then I'd wonder what was going on as that deep - they are the same thing [16:20] i'm booting into a live session, making changes for my company, then turning that session into an .iso to be used again [16:21] remastersys type thing - suppport is best for that [16:21] it isn't recognized as an .iso like when the dd command is done in ubuntu, but recognizes it as a raw dd image [16:21] okay [16:21] and to be honest #ubuntu has more eyes if it's slow in #ubuntu [16:43] flocculant, asking you again about the testing pages on the wiki - what do you want to do with them - should i just move them to the new wiki? [16:45] knome: hardware profile is dead, team hardware never really got much traction or use [16:45] flocculant, team hardware might be useful if it was linked in a sane way to the iso tracker... [16:45] flocculant, that said, i think it should probably come from your LP account, which is out of our reach [16:45] meant to discuss this the other day when I was editless on the wiki :p [16:45] heh [16:45] knome: the hardware option on the tracker is gone now [16:46] i know [16:46] so just delete the hardware page? [16:46] or would it be useful to track this in some other way? [16:46] well that or just move the used one to where we're moving [16:46] ok [16:47] i'll move it and we can then see what we want to do with it [16:47] i think there are some good bits there, like GPU stuff [16:47] no no [16:47] no? [16:47] :D [16:47] I meant just leave the 3 at wiki.u.c/xubuntu/testing [16:47] oh... [16:47] only have the release note on at the xubuntu wiki [16:48] i think that's actually the only one we want in the ubuntu wiki [16:48] ...considering we will be releasing the release notes there [16:48] why? [16:48] that's mostly because the markup is different [16:48] why aren't we moving that to ours? [16:48] oh mmm [16:48] not sure if the release team would be okay with that [16:49] or to be more exact, if they would just have them in one place [16:49] they aren't in one place :p [16:49] if they don't mind, then i'm fine with moving it [16:49] well, yeah... [16:49] that's why i said "rather" [16:53] https://wiki.ubuntu.com/WilyWerewolf/ReleaseNotes/Kubuntu [16:53] right [16:53] though they do have that page that links to another page [16:54] so the main release notes page links to wiki.ubuntu.com [16:54] the question is, can kubuntu, and could we, link directly to $something_else [16:54] and the other thing we've discussed before is if we need separate announcement/notes [16:54] clearly kubuntu doesn't do that (any more) [16:54] and then also, [16:55] well [16:55] one thing just occurred to me, there's the added benefit to staying in the ubuntu wiki that we can include the common stuff [16:56] if I was me looking in on the 2 of our things - the website 'ooh pretty' post would leave me cold - more inclined to want things like changes than that [16:56] well yeah [16:56] i do think that there's a place for both [16:56] yea [16:56] and they serve a different purpose (which are both okay) [16:56] just bringing that up [16:56] wiki for the detail, website for the sell [16:56] yes [16:56] and good point on includes [16:57] or from other POV, wiki for the technical stuff, website for the non-technical [16:58] yea that's my thinking [16:58] yep [16:58] thinking of includes though - then do we want to move the meeting stuff? [16:58] yes, since we're only including the meeting minutes [16:58] which should be moving too [16:59] so we can include internal - external is a problem? [16:59] yes [16:59] ok [16:59] or at least totally not so clean and dependable on [16:59] then we have to leave release notes on wiki.u.c imo [16:59] yes, that was what i was thinking [17:00] or it'd be some bizarre mishmash of what kubuntu did and the includes [17:00] which is meh [17:00] yeah, let's not mix two wikis together [17:00] nope [17:01] +1 on not mixing two wikis (without reading the discussion :p ) [17:01] ha ha [17:02] nice curry aroma here [17:02] flocculant, anyway, about the other testing pages... [17:03] flocculant, i would probably just remove the hw pages if those aren't actively used [17:03] flocculant, that said, if we figure out an active use for them, we likely want to move them to the new wiki because that's so much faster and we can control the stuff ourself [17:03] one is definitely pointless the other doesn't even have the QA lead on it [17:03] yep [17:04] ok [17:04] we can point those pages to the contributor docs [17:04] so people who access them aren't left in the cold [17:04] move https://wiki.ubuntu.com/Xubuntu/Testing/TeamHardware to us [17:04] mhm [17:04] kill the https://wiki.ubuntu.com/Xubuntu/Testing/HardwareProfile [17:04] ok [17:05] flocculant, would http://docs.xubuntu.org/contributors/qa-team.html be a fair target for the redirect? [17:05] anyway, dinner time [17:05] bbiab [17:05] not sure what you mean - ping me later [17:15] flocculant, i mean that when i "delete" the page, i could instead just point it to some other location [17:15] that would have somewhat relevant information [17:15] if somebody ends up to that page [17:16] can you not redirect to our wiki copy? [17:16] rather than docs [17:16] flocculant, for the "kill"? [17:16] oh sorry - thought you meant the other :D [17:16] no, that i will of course redirect to the new page [17:16] hang on - I think it's a copy of something else :p [17:16] haha [17:16] ok [17:17] https://wiki.ubuntu.com/QATeam/Hardware [17:18] redirect to there :) [17:18] i will [17:18] you can see where I've been on that page pretty easily :) [17:19] heh [17:19] what our qa docs don't have is anything about ordinary testers really [17:19] :) [17:20] the qa team page is really really qa team [17:20] yep [17:21] might get one done soonish - so it can all be up to date by release time [17:21] :) [17:21] I have another thing to add to the team page responsibility wise [17:21] remember we can update the website docs whenever we want [17:22] I didn't know that :) [17:23] I think I'll do that 'really' soon [17:23] then include link to that moved page [17:23] docs. is now on the dev server [17:23] so if you need anything changed there, you can ping me, pleia2 or ubottu [17:23] Unit193 rather [17:24] :) [17:24] ok - well I'll get this all done - then it can be updated, cos chapter 3 current is really chapter 6 ;) [17:24] yep [17:24] let's coordinate that then [17:25] yep [17:25] I'll make a start today on that [17:25] :) [17:25] I'll even add it as a task so I can look good :p [17:26] hahah [17:33] knome: mmm - so much of what I'll put in this tester page will link to places that exist in http://docs.xubuntu.org/contributors/common-reference.html#qa-team-links [17:33] so that will then end up with next to nothing in it [17:34] that's not referenced somewhere else - any need to keep that #qa-links do you think seperately? [17:51] so let's see.. [18:10] knome: do you mean wait and see? [18:10] wfm if so :) [18:13] for you, yes [18:13] http://wiki.xubuntu.org/qa/teamhardware [18:13] adding the redirect next [18:13] thanks [18:14] and done [18:14] mmm [18:14] just thought of a relevant point here [18:15] which is? [18:15] if I say to people - hey there is this list which we use to point specific people at testing things - they can't edit it ... [18:15] well [18:16] true, but they can't edit in the ubuntu wiki either if they aren't on the right teams [18:16] not as simply as people can wiki.u.c [18:16] and the page is (at least so far) team hardware [18:16] knome: yea - only really because way back it was a 'oh crud really need to get *this* tested on *that* - who in team can we pester [18:17] yep [18:17] but to be really useful it would be nice to tie active testers there [18:17] practically i don't see this as a big problem - those who we can depend on situations where we need exact testing are limited in quantity [18:17] I guess asking to edit that would lose the not active people [18:18] yea - same point :) [18:18] well, just tell them to be in touch with ~xubuntu-website and we'll create accounts for them [18:18] and will have read the dev docs - so not *just* drive by testers [18:18] yep [18:18] we'll have to consider the registration [18:18] but yeah [18:19] so far point people to -web [18:19] for the moment - not a major issue thinking more :D [18:19] anyway - thanks for doing that - means I have the link :p [18:19] yep, no [18:19] *np [18:19] :) [18:19] dinner time now [18:19] biab [18:19] bon appetit [18:22] flocculant, for when you get back... [18:22] flocculant, since https://wiki.ubuntu.com/Xubuntu/Testing/ is practically orphan now, do you want it to be redirected to the website page it has a link to right now, or to the contributor docs? [18:23] flocculant, or the new wiki landing page (which is quite quiet so far) [18:24] knome: I just need to be able to get at https://wiki.ubuntu.com/Xubuntu/Testing/ReleaseNoteBase [18:24] flocculant, i'll likely move it to Toolbox, but i'll poke you again then [18:24] when I say dinner time - I mean in and out while I'm doing it [18:24] ok [18:24] and removing that page doesn't stop you from getting there anyway [18:24] it's just a page without a parent [18:24] yea ofc - just making it plain I need it :D [18:24] well, a page with a parent that has a redirect... [18:24] ack [18:25] so where to point that? [18:25] https://wiki.ubuntu.com/Xubuntu/Testing/ > contributor docs please :) [18:25] http://docs.xubuntu.org/contributors/qa-team.html this one? [18:25] nope [18:26] it'll be qa-tester when it's there [18:26] ah, ok [18:26] i'll just point it there already... [18:26] :P [18:26] which will be chapter*1* of the qa stuff [18:27] and done [18:27] so testers - iso's - bugs - team [18:27] is the order [18:27] it's -tester now [18:27] should it be +s? [18:27] cool - ty :) [18:27] the file is tester [18:28] goodie [18:28] but can be +s :) [18:28] it's tester now! :P [18:28] \o/ [18:28] or testerooney :D [18:28] nooo [18:28] ha ha ha [18:28] neither testerole [18:28] see what i did there [18:28] tester(r)ooney [18:29] tester(c)ole [18:32] :) [18:46] bluesabre, interesting discussion on -release [19:09] davmor2 dkessel - upgraded 15.10 to 16.04 without apparent issue here jfi [19:11] flocculant: nice I'll do a run after I still think it is gcc that is biting us which would make sense as 14.04.4 is the much older version that is incompatible with the one in 15.10/16.04 but we'll see [19:13] yep - just thought I would let you know :) [19:14] flocculant: thanks [19:35] flocculant, you there? [19:36] ish [19:36] busy? [19:36] always - but often got time to talk to people as well :) [19:37] lol, if you please tell me a little in details about the email you sent to the mailing list about package tracker. [19:38] pavlushka: have you been to the package tracker? [19:38] ya [19:38] ok - so it is split into sections [19:39] yes [19:39] I can see that [19:39] the top section - all of those 7 have bugs listed against them [19:39] different category, different priority. [19:40] yes [19:40] basically test those applications - see if you can confirm the bug(s) [19:40] got it. [19:40] and? [19:40] it's been a while since I called for package testing - there have been lots of updates since then [19:40] good. [19:40] then report on the tracker - if you see the same bug - use the number listed [19:41] for example [19:41] http://packages.qa.ubuntu.com/qatracker/milestones/350/builds/105268/testcases/1559/results [19:41] right at the bottom - all the bugs people have seen [19:41] those need confirming again [19:42] you can 'me too' a bug - but most importantly - report on the tracker [19:42] on it [19:42] that is where I look [19:42] ok. [19:43] thanks [19:44] I might ask you if I had any confusions later about it. [19:44] yea that's fine :) [19:45] that's great for me, :) [19:45] :) [19:45] night. [19:45] I'm about for [19:45] sigh [19:46] I'm about for ~2 or 3 hours [20:17] knome: well that was hard work with me and bazaar for a minute there ... try and remember bzr add next time ... [20:17] anyway - done that now - index is right too [20:31] hahah :) [20:42] knome: I assume that docs update will grab the newest dvd/encryption stuff too? [20:43] yep [20:43] well [20:43] no [20:43] ok ... [20:43] because the 16.04 user docs aren't up already [20:44] oh right [20:44] but they are on the iso? [20:44] don't know if bluesabre and slickymaster coordinated a docs upload already [20:45] yeah, three days ago [20:45] well i did know [20:45] just didn't remember... [20:46] and no, the dvd stuff isn't in yet [20:46] that was merged after the upload [20:46] bluesabre, doc string freeze is this thursday, let's do another -docs upload on wednesday [20:46] flocculant, there ^ [20:47] knome: That doesn't matter for that though. [20:47] kryten: what doesn't matter? [20:47] kryten, string changes aren't subject to string freeze? o.O [20:47] knome: ack all that [20:47] Upload. [20:47] kryten, i acknowledge they are "bug fixes", but otoh, the freeze is there also for translations [20:47] k [20:48] kryten, technically, it doesn't block translators from doing their thing, but socially, i think it's good to do the upload before the freeze [20:49] we don't like others breaking freezes, and we shouldn't do that ourself, even if it only concerned us [20:52] so the end result of that is 'Wednesday' I think :) [20:52] yes [20:52] :) [20:53] knome: I agree that it's nice to do an upload when the final translation period begins, but wouldn't it make more sense to do that *after* the freeze then? :P [20:54] well, the process is that you do it before freeze because after that everything is frozen... [20:54] that's just how it goes [20:54] The strings are frozen. [20:54] nope [20:55] well, for us, practically, yes [20:55] but we can change them before thursday as much as we want [20:56] i guess this is minutiae related to the freeze process and customs [20:56] oh good [20:56] all freezes work in the "upload before freeze" way [20:56] if you want to land a feature, you will need to land it before the freeze [20:56] not upload it after the freeze [20:57] kryten, then there's of course the other freeze for translations [20:57] going to change all the the's to teh's and see if kryten notices [20:57] ;) [21:00] knome: Right, but IMO that's a bit different, feature freeze that is. String freeze is so translators don't have to hit a moving target. [21:01] Unit193, ack, but as i said, i don't think the question is technical but social [21:01] the fact that something is available and translatable somewhere is different than uploaded in the distro [21:01] Sure, but that's to address the latter arguments. [21:02] again practically not, but socially it means much that we put our work out and let everybody know what we're going with [21:02] i understand your point and don't really even disagree [21:02] but if we have upload permissions for the package and are not so limited in time that we really just can't get it in, it's good for all preparation to just do it [21:28] bluesabre: obviously! it's the gtk3 port that goes along with xfce 4.14 ;) [21:41] flocculant, Unit193, kryten: we should take it here though [21:41] but a target for .1, what about that? [21:41] flocculant: Right, and at this point can't really fine tune it anyway. [21:41] Unit193: ack [21:42] knome: *shrug* [21:42] freeze periods are shorter for .1, so a lot of time to tune it too [21:42] or it can be any other time we want to push it out, between main release and .1 too [21:42] let's wait and see what happens this week [21:42] sure [21:42] again just laying out potential options we might have to consider [21:43] so it's not "all lost" even we don't make main release day [21:43] yea ofc [21:43] * knome wants things to happen more than find guilty people ;) [21:43] myth didn't make release day with their 14.04 [21:43] yep [21:43] that's been done before [21:43] and this isn't ever our main image [21:44] yea - same - couldn't care what *happened* [21:44] just not going to say yea ok if I'm not happy is all :) [21:44] Little time to fine tune so that's not really great from my/dev standpoint, and of course I'll defer to flocculant anyway. [21:44] .1 would be August ish? [21:45] julyish [21:45] .2 februaryish [21:45] at least if the schedule is sameish to 14.04.xish [21:45] Point releases are created differently, sooo. Will have to diff the manifest. [21:46] Unit193, technical issue, that's overcomableish [21:46] right so - given b2 is next week and release is only 6 weeks - not going to be fun [21:46] :P [21:46] yes, that's why i brought up .1 already, even if we got base for b2 [21:47] if it makes it easier from the dev side (assuming assumptions) to do it for April - then we can but try [21:47] it depends on what response we get [21:48] I'd be much less happy +1ing core with 2 or 3 reports than I would the main images [21:48] yes [21:48] flocculant: Know of "anything wrong" with the current installer? [21:48] there's still a lot of variables, so releasing base with the main images in april totally isn't impossible either [21:49] but if we managed to get it right pre RC - that's 2 weeks to hack at testing it [21:49] Unit193: the normal image one - or the debian one ? [21:49] ubiquity. [21:49] nothing major that I know of [21:50] vbox things - but I ignore those anyway [21:51] swap issues for some [21:52] encryption oddities [21:52]