/srv/irclogs.ubuntu.com/2019/10/16/#ubuntu-devel.txt

LocutusOfBorgtjaalton, intel-media-driver-non-free intel-media-driver intel-gmmlib sync post eoan?09:04
LocutusOfBorgI'm trying to figure out if the delta can be dropped or not, just as a learning opportunity :)09:05
tjaaltonLocutusOfBorg: there's no real delta, so yes09:10
LocutusOfBorgthanks for confirming, I don't know if they can be syncd before release or not...09:30
LocutusOfBorgthey look like seeded...09:30
LocutusOfBorgso no09:30
LocutusOfBorg:D09:30
Unit193Maybe for Feisty Fawn.09:33
cjwatsonFawning Fist09:43
cjwatsonMaybe not09:43
Unit193Flailing Falcon.09:45
RikMillsFlacid Frog09:45
mwhudsonfarty fruitbat09:52
LocutusOfBorgMillenium Falcon :/09:53
LocutusOfBorgoops09:53
tarzeauFaboulous Ferryman10:25
cpaelzerrbasak: ahasenack: good news for haproxy and openssl12:01
cpaelzerthere is a patch that works to gain back control of the key size12:02
rbasako/12:02
rbasak\o/12:02
cpaelzerneeds a while to tickle through upstream for sure, but I confirmed it working in an experimental build12:02
=== ricab is now known as ricab|lunch
rbasakddstreet: how is progress on bug 1847242? Would it be worth releasing this at the same time as your previous autopkgtest SRU, or do you really want to release the current one first?12:48
ubottubug 1847242 in autopkgtest (Ubuntu Xenial) "adt_run test_tree_output_dir always fails on armhf" [Low,In progress] https://launchpad.net/bugs/184724212:48
ddstreetrbasak i can roll that in and reupload if you'd like12:50
ddstreetit's hardly the only flaky/failing autopkgtest for systemd on xenial (or other releases) though - i'm working from the top down (upstream, debian, then ubuntu) on correcting all that, so xenial was basically at the bottom of my list12:52
ddstreetah sorry this is for autopkgtest itself12:53
rbasakYeah12:53
rbasakAlso I just noticed that vorlon marked it block-proposed-disco when he accepted the Disco upload, but sil2100 perhaps didn't notice that when accepting Xenial and Bionic?12:54
rbasakAFAICT, there is no reason for the status to be different.12:54
rbasakSo perhaps we should mark it to hold for all three.12:54
rbasakAlso I need to document what that tag means.12:54
ddstreetyeah, it's actually *more* of a problem in disco, since people get the lxd snap there (which has the new behavior causing failure), while on bionic most people probably have the lxd deb, which is an older version and doesn't cause the failure (yet)12:55
ddstreetrbasak so i have the patch ready in my git and i can upload it for x now, but the new upload will have only the test fix (plus the fix that's in -proposed)12:59
ddstreetdoesn't matter to me either way really, if we wait then i'll include the test fix in my next autopkgtest upload to x whenever that might be13:00
rbasakddstreet: "...but the new upload will have only" -> why do you say "but"? Isn't that a good thing?13:07
rbasakThough13:07
ddstreetrbasak i just mean the new upload will only fix an autopkgtest; it won't include any new actual bug fix13:07
rbasakPerhaps it would be better if I didn't make any decisions here, actually, as I'd be the third SRU team member touching it and maybe that would just confuse things.13:08
rbasakddstreet: understood, thanks.13:08
rbasakI think it makes sense for you to upload, for use to add block-proposed-<series> for all outstanding stable series for that bug.13:09
rbasakHowever let's wait for vorlon or sil2100 to confirm.13:09
rbasakfor *you13:09
rbasakor maybe I meant us13:09
rbasakAnyway, I hope that makes sense13:09
sil2100rbasak: so I only accepted it into -proposed for bionic and xenial, I saw no reason for why not to include there with the block-proposed tag13:24
sil2100rbasak: ah, right, but we switched to using per-series ones only afterwards13:24
sil2100So the only thing I missed was actually switching the tags, yes13:25
=== ricab|lunch is now known as ricab
rbasaksil2100: thanks. So let's re-add those and get ddstreet to upload his next branch on top now then?13:42
sil2100Yes, added those13:46
Laneycyphermox: ahoy, I just bounced you an update translation tarball for ubiquity - could you integrate it quickly please?13:47
Laneynone of us here know how to do that /o\13:47
Laneyand we're planning an upload13:47
cyphermoxyup yup13:47
cyphermoxsil2100 just pinged me about it13:47
cyphermoxI was just wondering how come I had mail addressed to you13:48
cyphermoxtbh, it's nothing more than dropping the files on top of the existing ones, and renaming appropriately13:48
cyphermoxshould I look for a newly translated string in particular?13:51
sil2100cyphermox: not sure, I think the ZFS ones might have been additionally translated, but we just wanted to refresh the translations anyway since we're uploading a new ubiquity13:52
cyphermoxat least _Skip is translated in fr.po now13:53
sil2100cyphermox: \o/14:00
cyphermoxupdated.14:00
cyphermoxshould I upload too?14:00
sil2100cyphermox: yes please14:00
cyphermoxack14:00
rbasakrafaeldtinoco: reviewing your simplestreams Xenial SRU, I'm not sure I follow why an SRU is necessary for about half of these bugs - relating to v3 support14:19
rbasakI'm not aware that we usually backport new features to old LTSes due to new features/deprecations in future OpenStack releases - that's what I thought the cloud archive was for.14:20
rbasakAm I wrong, or is this case exceptional somehow?14:20
rafaeldtinocorbasak: it was a seg request14:20
rafaeldtinocobecause of a charm14:21
rafaeldtinocolet me open the lps14:21
rbasakSo a statement like "The OpenStack Keystone charm supports v3 only since Queens and later" doesn't help me - why doesn't the charm support the older version?14:21
rafaeldtinocook.. so, with xenial, the keystone charm has to use simplestreams from a ppa in order to make it work whenever updating openstack14:21
rafaeldtinocothe upgrade procedure needs v3 support for not to brake14:22
rafaeldtinocobecause of the ordering (services)14:22
rafaeldtinocobut i must confess Im relying mostly on freyes feedback14:22
rafaeldtinocofreyes: ^ do you have something else to add for rbasak  ?14:22
freyesrbasak, >=Queens OpenStack dropped support for Keystone v214:23
rbasakfreyes: and the cloud archive provides Queens against Xenial as a backport, correct?14:23
freyesrbasak, correct14:24
rbasakOK, so shouldn't this simplestreams v3 support to into the cloud archive, and not the Ubuntu Xenial archive, to solve that problem?14:24
rbasakgo14:24
freyesrbasak, the cloud archive doesn't carry the simplestreams package, and if there is an intention to do it for newer releases it won't help with this bug14:26
rbasakI don't think that "doesn't carry the simplestreams package" automatically means that an SRU is justified, though the SRU team might conclude that it's OK if no other solution makes sense.14:27
rbasakBut I don't understand why the package couldn't just be added to the cloud archive14:28
rbasakJust because it's not there right now doesn't mean it can't be added right now.14:28
rbasakIt'd bump users up, but that's what you'd be doing with the SRU anyway.14:28
freyesanother reason why we may want to fix the package in distro is because simplestreams being a client, it could be that someone just wants to talk to a cloud that runs keystone v3, so in the case you propose, they would need to add a cloud archive repo (pulling a lot of new packages)14:31
freyesI see pros and cons on both ways14:31
rbasakThat's the same situation for any network protocol client in Xenial though, OpenStack or not.14:31
rafaeldtinocoa question that triggers me is..14:32
rafaeldtinocoinstead of a SRU to cloud archive14:32
rbasakWe expect such clients to use a newer release, or a snap, or some backport PPA, etc.14:32
rafaeldtinocowe would have to have the backport instead14:32
rafaeldtinocoso there is a 1:1 relation with newer fixes14:32
rbasak(or run in a container of a newer release; the list goes on)14:32
freyesrbasak, true, disregard my last thought14:33
rbasakrafaeldtinoco: yes - that's a decision for the cloud archive maintainers, but I agree that a backport would make more sense.14:33
rbasakHowever, the downside is that it's quite late to be doing such a backport - it might be more than you want to bump existing stable users (same concern as an SRU backport).14:33
rafaeldtinocojamespage: ^ can we have simplestreams included in cloud-archive ? this way the following SRU is not needed and, instead, the resolution would be to add the cloud-archive in order for xenial glance (>= queens) to support keystone v3 ?14:34
rafaeldtinocoi would document that in all those LPs and end user would have a place where to look if ever facing this need.14:35
freyesit would be add the simplestreams in bionic to the xenial-queens archive14:35
jamespagesimplestreams in bionic does not work with keystone in bionic outside of any charm context due to the drop of the v2 API at queens release, which is what's in bionic14:36
jamespagetl;dr its broken in distro14:36
jamespagerafaeldtinoco, rbasak: ^^14:37
rbasakjamespage: that might just mean that we need to fix Bionic in an SRU first though - I don't think it affects my proposal for a resolution in Xenial?14:39
rafaeldtinocofixing simplestreams in Bionic and having it available in cloud-archive for xenial (this is current suggest, right ?)14:39
rbasakThat's what I'm suggesting, yes14:40
jamespageoh right - sorry i missed that context - yeah fix it in bionic, and we will include it in the UCA for xenial/queens14:40
rafaeldtinocogood.14:40
* jamespage needs new glasses (or new eyes)14:40
rafaeldtinocofreyes: i can backport same patches to bionic and have u reviewing them if you're ok14:40
freyesrafaeldtinoco, I'm cool with that ;-)14:40
rafaeldtinocoand then we ask jamespage (tks) to include it in cloud-archive14:40
rbasakOK, thanks!14:40
rafaeldtinocotku all!14:40
freyesrafaeldtinoco, appreciated for chasing this14:41
=== bdmurray_ is now known as bdmurray
=== CarlFK is now known as PedroFK
=== PedroFK is now known as CarlFK
rbasakxnox: are you aware of bug 1846787, and do you have any opinion on this one please? I'm thinking that your review would be better than mine on this one.16:03
ubottubug 1846787 in systemd (Ubuntu Xenial) "systemd-logind leaves leftover sessions and scope files" [Medium,In progress] https://launchpad.net/bugs/184678716:03
Pharaoh_Atemcyphermox: can you please take a look at this for xenial? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/182424518:28
ubottuLaunchpad bug 1824245 in grub2 (Ubuntu Xenial) "Can't create a bootable disk by doing image creation on a loop device" [Medium,Triaged]18:28
Pharaoh_AtemI've included an updated patch for the ubuntu grub2 packaging following what cjwatson asked me a month ago...18:29
cyphermoxPharaoh_Atem: as soon as I have a bit of time to context switch back to grub2, I will18:36
Pharaoh_Atemcyphermox: any idea when that will be?18:44
cyphermoxsorry, not really. for now I really need to focus on netplan19:34
cyphermoxthere is another SRU to land for xenial, so once I hear from it I'll try to make sure this patch lands alongside it19:34
tomreyndid something change about which crashes whoopsie on 18.04 would (not) report, or which of them are shown at https://errors.ubuntu.com/user/$(sudo cat /var/lib/whoopsie/whoopsie-id) ?20:06
tomreynthe last report i see listed for this desktop system is from august, but i have certainly subbmitted additional crash reports since.20:07
tomreyns/august/july/20:08
tomreynanyone running 18.04 lts, that is20:10
tomreynscratch (just) the last line, i meant to post this to #ubuntu-discuss20:11
popeyfrom an enthusiastic user who just installed 19.10...22:32
popey"Tell everyone they are doing amazing work with this release and it's highly appreciated"22:32
popeyJust thought I'd pass that on.22:32
Unit193I shift in the shadows, poking at the things most people don't care about.  It's not meeeeee. :322:37
infinitypopey: It's not the guy who emails us every time he downloads a new ISO, is it?23:06
popeyNo :)23:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!