[00:55] <mwhudson> tsimonq2: congrats
[08:08] <darkxst> bdmurray infinity, re bug 1751546, what generates the tasks in the archive, is it related to the germinate cron job that was disable last year?
[08:08] <ubottu> bug 1751546 in tasksel (Ubuntu) "the net installer doesn't install gnome-vanilla" [High,Triaged] https://launchpad.net/bugs/1751546
[08:14] <infinity> darkxst: See my follow up.
[08:17] <cpaelzer> when I run the same gcc command on Debian and Ubuntu where does the collect2 gets its args from
[08:17] <cpaelzer> They differ in my case between Debian and Ubuntu causing an issue (for Debian) that I want to resolve/understand
[08:18] <cpaelzer> I moved to the gcc-7 in our proposed so both are 7.3.0-11 based
[08:18] <infinity> cpaelzer: From the gcc spec and/or build options.
[08:18] <cpaelzer> I thought I compared the gcc -v and other parts of a verbose build
[08:18] <infinity> cpaelzer: gcc -dumpspecs will give you a (messy) view of that world.
[08:19] <cpaelzer> infinity: can I let gcc list the build in defaults?
[08:19] <cpaelzer> let me check that infinity
[08:19]  * cpaelzer goes messy
[08:19] <infinity> cpaelzer: But it's probably easier to tear open debian/rules* in the source package and see how the build differs between Ubuntu and Debian.
[08:20] <cpaelzer> infinity: I
[08:20] <cpaelzer> I'm already down toa simple commandline gcc call
[08:20] <cpaelzer> behaving differently
[08:20] <cpaelzer> and the dumpspec seems to prove that
[08:20] <cpaelzer> I found what I assume to be the difference
[08:21] <cpaelzer> Ubuntu has in the *link step "... --hash-style=gnu   --as-needed   %{shared:-shared} ..." while debian lacks the --as-needed in the same
[08:21] <infinity> cpaelzer: Oh, yes.  We've been using as-needed for ages.
[08:21] <infinity> cpaelzer: Have you really never tripped on that before today? :)
[08:22] <cpaelzer> I tripped over it about 5 times I think
[08:22] <cpaelzer> but not that Debian started to differ, because it didn't a while ago
[08:22] <infinity> cpaelzer: If that's causing you issues, the answer is almost always not "the compiler is doing something silly" but "the build system is doing something silly".
[08:22] <infinity> cpaelzer: command-line order matters with as-needed because deps are searched left to right.
[08:23] <infinity> cpaelzer: And no, Debian didn't "start to differ" here, we've been diverged on as-needed for half a decade or so.  Since before you joined Canonical.
[08:23] <cpaelzer> interesting
[08:23] <cpaelzer> infinity: I actually fixed it in the build system of the package a year or so ago
[08:23] <cpaelzer> but our dep8 test needs all that fixed up as well now
[08:23] <cpaelzer> infinity: thanks for the right pointers
[08:24]  * cpaelzer need to check old debian test logs ...
[08:24] <cpaelzer> yep, you are right (as always) the difference was there in the past as well
[08:25] <cpaelzer> it just now became an issue due to other changes
[08:25] <cpaelzer> perfect, I think I can work this out now
[08:28] <infinity> cpaelzer: Assuming you didn't fix it in an obscurely hackish way, you should forward those changes upstream.   as-needed fixes are always technically correct, and we're not the only distro that uses it as a default.
[08:29] <infinity> We should probably reopen that discussion with Debian too, so we don't trip on the bugs first. :/
[08:31] <cpaelzer> infinity: as I said upstream is good (in a non hacky fashion), I just want to fix the dep8 tests now so they work on Debian and Ubuntu without tripping over this
[08:31] <cpaelzer> I think I can plug into the upstream build system on the test, which is actually more correct than a direct gcc call for the test anyway
[08:31] <cpaelzer> needs some checks if it works as I plan it atm
[08:32] <mwhudson> wait --as-needed isn't the default always and forever?
[08:32] <infinity> cpaelzer: Well, fixing the gcc call is likely trivial too.
[08:32] <mwhudson> til
[08:33] <infinity> cpaelzer: You're likely doing something like "gcc -o foo.o -lbar -lfoo bar.o baz.o", just moving the libraries to the end will fix it.
[08:34] <infinity> cpaelzer: The linker evaluates from left to right, and when it sees a library, checks if anything already linked references the library.  If not, it discards it.  Putting the libs at the end makes sure the earlier object references are already in play.
[08:34] <darkxst> infinity, I guess vanilla-gnome-desktop was our attempt to keep the predicted 50% of ubuntu-gnome population that still want a un-modified upstream GNOME package
[08:34] <darkxst> keep them happy
[08:35] <infinity> darkxst: I suspect that 50% is rather high.  Most people don't actually care that deeply about such details.
[08:35] <infinity> darkxst: (See the fuss that nerds make about a vanilla AOSP experience, while 99% of Android users really don't care at all and use whatever came on their phone).
[08:36] <cpaelzer> infinity: it essentially is "gcc test.c -o testl.bin `pkg-config ...` and pkg-config brings in the stuff that then gets a bunch of "-l.." in (at the end which is correct per your comment above)
[08:36] <infinity> darkxst: And I'm not saying the metapackage shouldn't exist.  We have metas for upstream KDE and XFCE (and other) experiences too.  But we don't have them in tasksel.
[08:36] <cpaelzer> infinity: it works to build on both, but it increases the things linked and we checked on some of that
[08:37] <cpaelzer> that is why I mean I want to fix mostly the test
[08:38] <darkxst> infinity, its a hard thing to predict though! how many people used ubuntu-gnome just to get gnome-shell and how many still dislike the ubuntu themes!
=== LtWorf_ is now known as LtWorf
[08:40] <darkxst> infinity, if its made into just another generic task, how do we avoid it getting lost in the sea of generic tasks?
[08:41] <infinity> darkxst: s/task/package/?
[08:41] <infinity> darkxst: And we don't avoid it getting lost.  I mean, this is a super nitpicky "power user" thing.  We have no official flavour supporting this.
[08:41] <darkxst> also it still has upload rights attached to the packageset, which the DMB are proposing to expand in order to get rid of desktop-extra
[08:42] <infinity> darkxst: From my POV, it's better to have it difficult enough to find that the picky people have to know where to look.
[08:50] <darkxst> infinity, it didnt really make sense to spin ISO's anymore, with Ubuntu moving to gnome-shell, but we fully intended to maintain the vanilla-desktop session
[08:51] <infinity> darkxst: I mean, sure.  Maybe that's true.  But on the flipside, the supported upgrade path for Ubuntu GNOME is to Ubuntu.
[08:51] <infinity> darkxst: ubuntu-gnome-desktop depends on ubuntu-desktop, and the release-upgrader makes that same assumption.
[08:52] <infinity> darkxst: So vanilla-gnome-desktop is very much a "weird power user" thing, just like any other vanilla DE experience.
[08:53] <infinity> darkxst: xubuntu more or less supports the vanilla xfce experience too (since it happens to land in their packageset), but there's no installer support for it, and it's very much a grey area of "supported, but not recommended, and not the product they focus on".
[08:59] <darkxst> infinity, ok I will change tasksel to use package instead
[09:03] <juliank> I don't understnad the vanilla-gnome stuff. It seems to override stuff in gsettings that's handled by per-session defaults, and work just fine by using the gnome session.
[09:12] <darkxst> juliank, there might still be some overrides in there that are now redundant, with Ubuntu switching to gnome-shell
[09:13] <juliank> Did USB audio break recently? I see my DAC just fine in alsa, but PulseAudio does not detect any sink on it...
[09:15] <juliank> external mic is broken too
[09:50] <cpaelzer> is there a best practise what set of ruby triggers to add on autopkgtests that fail due to the ongoing transition?
[09:53]  * cpaelzer goes lazy and tries locally with all proposed
[10:03] <cpaelzer> bdrung: any time to updates on bug 1753938?
[10:03] <ubottu> bug 1753938 in qemu (Ubuntu) "slirp: domainname and classic stateless for DHCP" [Undecided,New] https://launchpad.net/bugs/1753938
[10:03] <cpaelzer> how is upstreaming the changes going atm?
[10:11] <doko> gcc-6 demoted \o/
[10:15] <cpaelzer> gz doko!
[11:21] <tsimonq2> mwhudson: thanks
=== ginggs_ is now known as ginggs
[12:05] <enyc> Somebody being assigned to  1601997 1365874  for 18.04 ?
[12:08] <rbasak> bug 1601997
[12:08] <ubottu> bug 1601997 in e2fsprogs (Ubuntu) "Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs" [High,Triaged] https://launchpad.net/bugs/1601997
=== mhcerri_ is now known as mhcerri
[12:10] <enyc> rbasak: thats the killer,  1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too...  tytso himself encourages!
[12:11] <enyc> Secondarially, backporting e2fsprogs and grub2 in 16.04 and 14.04 would be helpful,  but less urgent if 18.04 (sensibly) rolls back the needless extra filesystem-flags.
[12:12] <rbasak> To save others reading the bug, it's that Debian has enabled metadata checksumming by default, so filesystems created by the installer can no longer be fscked (possibly also not be mounted? Unclear from the report) by older LTS releases.
[12:12] <rbasak> cyphermox perhaps? ^
[12:12] <enyc> some verison can't even mount
[12:12] <enyc> in any case its' a very annoying needless compatibility problem
[12:12] <rbasak> But it looks like Debian have no intention of putting that into stable.
[12:12] <rbasak> Seems like a relatively trivial FFe to undo.
[12:13] <rbasak> (some theoretical risk of installer regression but seems unlikely to me)
[12:13] <enyc> rbasak: undo the extra feature?
[12:13] <enyc> [put back mke2fs.conf from older e2fsprogs, specifically]
[12:13] <rbasak> Yep
[12:14] <rbasak> Seems reasonable to me, but someone closer to the installer packages should decide
[12:14] <rbasak> Or the release team.
[12:14] <enyc> however, on the FFE front, tytso also reccomends we strongly consider e2fsprogs upgrade to 1.44  (though this is separate matter)
[12:14] <enyc> would like support for some (non-default, but useful for some) flags  included from the outset in LTS
[12:15] <rbasak> enyc: do you have references for that recommendation specifically please?
[12:15] <enyc> rbasak: "1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too..."
[12:16] <rbasak> Bug 1365874 seems unrelated to bumping to 1.44 to me.
[12:16] <ubottu> bug 1365874 in e2fsprogs (Ubuntu) "Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming" [Medium,Triaged] https://launchpad.net/bugs/1365874
[12:16] <enyc> rbasak: read comemnts, i check
[12:17] <enyc> See comment #17 onwards
[12:17] <enyc> i can see now there maybe should be many different bugs ;p
[12:17] <rbasak> I see thanks.
[12:19] <rbasak> slangasek, gaughen: ^ worth taking a look IMHO (not recommending we do it, just that it's worth considering).
[12:19] <enyc> NB:   In MY view there are 4 actions in decreasing priority :   (1): revert mke2fs.conf in 18.04   (2): Upgrade e2fsprogs to 1.44.0 while keeping change 1   (3): Backport E2fsprogs [1.44.0 to Xenial] [1.43.9 to Trusty]    (4) Backport Grub2 (at least 2.02beta3) to Xenial and Trusty.
[12:20] <enyc> I have not yet found/created a bug about 4
[12:20] <rbasak> slangasek, gaughen: I tagged 1365874 for you. We don't have a bug specifically on syncing 1.44.0-1 right now, but that's mentioned in https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/comments/17
[12:20] <ubottu> Launchpad bug 1365874 in e2fsprogs (Ubuntu) "Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming" [Medium,Triaged]
[12:20] <rbasak> enyc: thank you for drawing attention to this.
[12:20] <rbasak> enyc: backporting is much harder process-wise because of the risk of regressing users of stable releases.
[12:21] <rbasak> enyc: but that can be quite separate as it doesn't have a deadline like Bionic does.
[12:21] <enyc> rbasak: its going to cause all sorts of multi-booting and datacentre lvm/ext4 crap and weird things if not attended to.
[12:21] <enyc> (1) is most important, risk-averse, imho =).
[12:22] <rbasak> IMHO it's inconvenient, but acceptable, if an older release can't read a filesystem created by a newer release. That's the only way to move forwards sometimes. But if we can avoid the inconvenience at little cost, then it can be worth doing. It's a judgement call that needs to be made, and it's not my call.
[12:22] <enyc> rbasak: nodsnods
[12:22] <enyc> so far as I can see  its not really losing anything to revert...  we don't need >16TB support on ALL fs, and the extra csum is nonly if you have bad disk already sort of thing...
[12:23] <enyc> thankyou for understanding and being interested to make "informed choices"[!]
[12:29] <jbicha> juliank: I think it would be useful to drop the gsettings overrides from ubuntu-gnome-default-settings (moving some of them to ubuntu-settings)
[12:29] <jbicha> ran out of time this cycle
[12:48] <cyphermox> rbasak: if you're talking about an e2fsprogs FFe, up to you
[12:51] <cyphermox> I'm fine with a backport of e2fsprogs, but this sounds like it has nothing to do with an "installer bug"
[12:51] <enyc> I Guess a Single FFE could be used, import e2fsprogs AND revert (just for 18.04) the 64bit,metadata_csum change.  I note this makes a 'udeb' for the installer TOO, need to check.
[12:51] <cyphermox> no, that's not the point.
[12:52] <cyphermox> there are two options: either add metadata_csum to old releases by backporting, or reverting everywhere
[12:53] <cyphermox> it's orthogonal to having a newer e2fsprogs in 18.04.
[12:53] <enyc> I noted in bug, canonical partners may have views, onther non-ubunut-systems they support/interoperate w too.
[12:53] <enyc> cyphermox: sure inded, but both (1) (2) go in same package/change/FFE
[12:54] <enyc> backports complex SRU process apparently
[12:54] <rbasak> cyphermox: that's not exactly the reason for my ping. I'm more bothered about whether we want metadata_csum on by default in Bionic, leading to installed filesystems that can't be handled by older releases. Is that something we can avoid by turning it off by default?
[12:55] <cyphermox> enyc: my point is, you're mising up different processes
[12:55] <rbasak> cyphermox: and separately, should we sync e2fsprogs to get the newer upstream release (which is a mostly unrelated question)?
[12:55] <cyphermox> rbasak: I value filesystem integrity. My opinion is that we should keep it on if possible, especially looking forward
[12:56] <enyc> tytso had views on both, he's ONLY JUST introduced metadata_csum by default in e2fsprogs,  he only put it on in debian a while ago to get  "testing exposure"  amongst more-technically-able-community
[12:56] <cyphermox> rbasak: re: newer upstream, I'd say it missed the mark?
[12:56] <rbasak> cyphermox: another way would be to wait an LTS cycle so that it can be brought in but while maintaining the ability of the previous LTS being able to handle the following LTS' filesystems.
[12:57] <cyphermox> rbasak: tbh, I'd backport it, if the kernel in xenial-release supports it.
[12:58] <rbasak> Since my ping, it occurred to me that perhaps messing with filesystems across different releases is a more server-y use case.
[12:58] <rbasak> I'll see what my team thinks.
[12:58] <enyc> think about dual-booters users...
[12:58] <enyc> i've had many cases of older relase, wanting to rewrite/upgrade grub
[12:58] <enyc> which then BREAKS the newer release booting
[12:58] <rbasak> cyphermox: I appreciate your comments. I understand it's a trade-off. IMHO, I'd like us to make some decision and document it, eg. by closing the bug and release noting it.
[12:58] <enyc> unless you go out of your way to  dpkg-reconfigure grub2  and tell it NOT to install grub any more
[12:59] <cyphermox> rbasak: sure
[12:59] <cyphermox> enyc: have you filed bugs about it?
[12:59] <enyc> rbasak: I also don't think its an "either-or" case... its difficult either way.  "-backports" are not installed by default, I thought, too...  My "risk-managed" appreach would be to revert (only) for 18.04 and also start arranging backports afterwards.
[13:00] <cyphermox> rbasak: well, this would be a question for not just the server team, perhaps to bring up on ubuntu-devel@
[13:00] <enyc> cyphermox: its all in those 2 bugs above, but its important to see the history.  if a "please backport grub2 as well" is wanted, i can create another bug there too.
[13:00] <cyphermox> rbasak: arguably you're just making sure e2fsprogs supports the feature, it could be "off by default" in the backport.
[13:01] <enyc> cyphermox: YES thats a godo risk-managed approach
[13:01] <rbasak> Agreed (to both)
[13:01] <enyc> not everybody will install/have the backports, etc etc.  theres' little-adavantage to the feature, so.
[13:01] <cyphermox> enyc: if you're written about a grub issue in the e2fsprogs bug, it's been missed
[13:01] <enyc> cyphermox: menitoned in there
[13:01] <rbasak> There's the separate question of whether the older kernel will mount it. Do we know?
[13:02] <enyc> rbasak: from what i can see, trusty requires HWE kernel, xenial doesn't (i.e. 4.4 is ok)
[13:02] <cyphermox> enyc: please file a separate bug about the issue, then we can decide if it warrants a backport or not (I think most likely not, but I can fix the bugs)
[13:02] <enyc> rbasak: but don't forget about other distros people use about,  its not an ubuntu-only world
[13:02] <rbasak> enyc: that doesn't sound too bad. Thanks.
[13:02] <cyphermox> rbasak: not sure
[13:02] <cyphermox> tbh, I wouldn't backport to trusty?
[13:03] <cyphermox> hrm
[13:03] <enyc> cyphermox: ok it may be this evening i do it, but i'll try to grub2 backport separately, link to the other 2 related bugs.
[13:03] <cyphermox> otoh you "could", and depends on the hwe kernel then
[13:03] <enyc> cyphermox: tytso had comments on that to..  I must stress reading ALL commends on both bugs.
[13:03] <enyc> will do
[13:03] <enyc> thankyou for starting to think, i know its complex
[13:03] <cjwatson> If there's a grub change required in older releases, it should be a small cherry-pick, not a full backport
[13:04] <rbasak> Imagine if we had a policy on this (just hypothetical; I'm not suggesting that we should). That policy might say "mounting/fscking a filesystem created by a future release is not supported", or "we maintain backwards compatibility for filesystem fsck and mount but no further than one LTS" or "we maintain compatilbity to all supported releases".
[13:04] <cjwatson> We normally use the term "backport" for backporting full new releases, rather than cherry-picking individual commits
[13:04] <rbasak> If we were to pick the middle option, then not backporting to Trusty would be reasonable.
[13:04] <enyc> cjwatson: nods!  and it would be easier if that wasn't needed (for now) by 18.04 not using the controversial-to-enable extra-feature.
[13:04] <enyc> rbasak: agreed
[13:06] <cyphermox> rbasak: there's prior art saying it's "supported", at least to some degree
[13:06] <rbasak> OK.
[13:06] <cyphermox> that said, now I think we should backport to trusty too if we do it at all
[13:07] <cyphermox> the metadata_csum change looks to have been made in yakkety
[13:07] <enyc> IMHO if my (1) (2) can be done now, (3) (4) applying to trusty can be decided after-18.04-release if that helps.
[13:07] <rbasak> And to clarify, that means I think there a few ways of getting to "supported" - by disabling metadata_csum by default on Bionic, by having the installer override it to not use it by default, or by backporting the necessary support to older releases.
[13:07] <cjwatson> enyc: However, are you actually sure a GRUB cherry-pick is required?  Your comment is very vague.  64-bit support was added to GRUB's ext2 driver before trusty.
[13:08] <rbasak> (my middle option is technically possible but seems too surprising to users to me to want it)
[13:08] <cyphermox> rbasak: scratch the installer out of that, it's not the issue -- it will just use whatever is default
[13:08] <enyc> cjwatson: im not sure, it would best need testing.  it could be the metadata_csum thats confusing it.   There is a lot of confusion about if  its' 64bit or metadata_csum that causes particular issues or not.
[13:08] <rbasak> Yep
[13:08] <enyc> cjwatson: there is some other grub devel messages about realizing they can just ignore metadata_csum entirely, and not sure when that was commited.
[13:09] <cjwatson> enyc: I think you are mistaken.
[13:09] <cjwatson> Or possibly confusing something.
[13:09] <cjwatson> There's the metadata_csum thread which I started; I don't think anything has been committed for that yet
[13:10] <cjwatson> But that's metadata_csum_seed
[13:10] <enyc> cjwatson: thats what im saying ,there is confusion about between the 2 changes (which tended to come in together).  I'm saying, IMPORTANTLY that its ONLY JUST been turned on in  e2fsprogs by default within DAYS,  tytso also turned in on in debian "to get extra testing amongst more technically skilled".
[13:10] <cjwatson> Which I don't think is what you're talking about here.
[13:11] <enyc> cjwatson: indeed not, csum_seed is another matter
[13:11] <cjwatson> There were no other relevant changes since 2.02~beta2.
[13:11] <cjwatson> (regarding either of the features you mention)
[13:12] <enyc> cjwatson: I am 100% aware facts would need to be double-checked over 64bit vs metadata_csum.  defenitely found anecdotes that 64bit compatibility required 2.02~beta3 ... would need test or investigate.
[13:12] <enyc> which is in part why not posted bug baout that (4) aspect yet
[13:12] <cjwatson> Your anecdotes, my checking the git history ... hmm, I wonder which is more accurate :)
[13:12] <enyc> and what change is marked properly in git
[13:13] <enyc> has some other change, fixed a bug that stopped that case working?
[13:13] <enyc> i don't know
[13:13] <cjwatson> The number of changes to the ext2 driver in GRUB is very small
[13:13] <enyc> https://www.linuxquestions.org/questions/slackware-14/install-grub2-on-current-failed-4175580346/
[13:14] <enyc> I'm well aware that area is uncertain and would need cecking/testing for bug to be raised w/ clear facts.
[13:15] <enyc> Given that upstream e2fsprogs has ONLY JUST turned on 64bit,metadata_csum by default i'm not suprised if there are many issues and confusion lurking.
[13:18] <cjwatson> All I'm saying is that it's unlikely that randomly updating the GRUB source will do anything here, because there are no changes that appear relevant.  (There are changes related to the meta_bg and mmp features, and one or two other bug-fixes.)  That linuxquestions thread is really too vague to be meaningful ...
[13:19] <cyphermox> enyc: have you opened that separate bug report for the grub issues you're seeing?
[13:19] <cjwatson> Filesystem drivers in GRUB are quite well-isolated; for this kind of thing it would be unusual for any change to any file other than grub-core/fs/ext2.c to be relevant.
[13:23] <bigon> https://bugs.launchpad.net/ubuntu/+source/libnative-platform-java/+bug/1683761 https://bugs.launchpad.net/ubuntu/+source/libnative-platform-java/+bug/1754896 << Is anything missing for these bugs?
[13:23] <ubottu> Launchpad bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [Undecided,In progress]
[13:23] <ubottu> Launchpad bug 1754896 in libnative-platform-java (Ubuntu) "Sync libnative-platform-java 0.14-3 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
[13:27] <cyphermox> bigon: I don't think so, looks all bugfixy
[13:29] <cyphermox> tdaitx_: opinions? ^
[13:37] <tdaitx_> cyphermox: bigon: seem all clear, maybe we should bump LP: #1754896 from whishlist to high as it would fix LP: #1683761 for bionic
[13:37] <ubottu> Launchpad bug 1754896 in libnative-platform-java (Ubuntu) "Sync libnative-platform-java 0.14-3 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1754896
[13:37] <ubottu> Launchpad bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [Undecided,In progress] https://launchpad.net/bugs/1683761
[13:38] <enyc> cyphermox: as above comments, i've said 2 things -- one would need to fact check to put in a decent grub report, two might be able to do that this evening.
[13:39] <cyphermox> enyc: ok
[13:39] <enyc> cjwatson: noted!  your investigations, suspect that grub2 back to xenial (only?)  what about trusty,  ought to be compatible with 64bit,metadata_csum ?
[13:40] <enyc> one big risk is that a dual-boot installer goes ahead, then  older system (when booted-into, and updated) re-installs its own grub and breaks booting new-system.
[13:40] <cyphermox> bigon: tdaitx_: cool. I will sponsor that then
[13:40] <tdaitx_> tks ;-)
=== tdaitx_ is now known as tdaitx
[13:45] <cjwatson> enyc: Your guess about my investigations is wrong; I checked back to 2.02~beta2, which is in trusty.
[13:46] <enyc> cjwatson: i asked you "what about" and a (?) in there, i did not 'guess'
[13:46] <enyc> cjwatson: so, your investigahions suspect both should be ok
[13:47] <enyc> acid-test is to bios-mode install a 14.04, and a 18.04-test dual-boot, then update-grub on the 14.04
[13:47] <cjwatson> enyc: "suspect" = "guess" :-)
[13:47] <cjwatson> enyc: I currently see no reason why trusty's GRUB would be incompatible with 64bit,metadata_csum
[13:48] <cjwatson> enyc: You can also just use grub-fstest from 14.04's GRUB packages (would probably even be doable in a chroot)
[13:48] <cjwatson> enyc: Or indeed grub-probe
[13:48] <enyc> cjwatson: right yes sure,  though given upstream have ONLY JUST turend on the flag-by-default (in days!!!) theres every possibility of not-well-tested/bugs in that regard too,  worthy of some test.
[13:48] <cjwatson> enyc: Basically all GRUB's filesystem code can be run from userspace
[13:49] <cjwatson> enyc: Sure, but in that case 16.04 would be incompatible too.
[13:49] <enyc> cjwatson: yes, assuming any other "seemingly unrelated" chainge doesn't affect it.  acid-test should prefer the older-version.
[13:49] <enyc> noted
[13:50] <enyc> cjwatson: thankyou for the pointer abou grub-probe grub-fstest ...
[13:53] <cjwatson> Bet you a tenner such a seemingly unrelated change doesn't exist. :-)
[13:53] <enyc> haha
[13:53] <cjwatson> (I understand the caution in general; my confidence is based on experience with how GRUB's filesystem code is laid out.)
[13:53] <enyc> sure !
[13:54] <cjwatson> I think it's much more likely that confusion is caused by *different ext[234] features*.
[13:54] <enyc> howso? e.g. the _csum or something else?
[13:54] <cjwatson> That linuxquestions thread you posted had a bunch of changes in mke2fs.conf.
[13:54] <enyc> right yes
[13:55] <cjwatson> So I'm suggesting it's more likely that one of those relates to one of the *known* changes since 2.02~beta2.
[13:55] <enyc> useful feedback, still worthy of test hopefguly this evening,  so I can then post grub2 backport bug as relevant
[13:55] <cjwatson> And that this is probably entirely unrelated to proposed changes in Ubuntu 18.04.
[13:55] <cjwatson> Not backport, please.
[13:55] <cjwatson> Cherry-pick, *if anything*.
[13:55] <enyc> right i see
[13:55] <cjwatson> Saying "backport" invokes quite the wrong set of processes.
[13:55] <enyc> yes i mean  "grub2 needs fixing for compatibility, heres why, heres where it goes wrong"
[13:55] <enyc> agreed
[13:56] <enyc> whereas, e2fsprogs-wise,  tytso reccomends backport  interestingly.
[13:58] <cjwatson> Upstreams nearly always do.
[13:58] <cjwatson> We don't always agree :)
[13:58] <enyc> nodsnods
[13:58] <enyc> yes i was wondering something along those lines
[14:01] <enyc> cjwatson: nonetheless... what do you make of this aspect...  tytso has "only just" turned on  64bit,metadata_csum upstream, 'for everyone',  --  he only turned it on in debian  for extra testing,  talks about " the average technical sophistication of a Debian vs. a Ubuntu user, compatibility constraints with Ubuntu LTS, etc."
[14:01] <enyc> we've ended up with 'decision by default' sofar
[14:01] <enyc> i guess he's also being conservative...   i don't know about  generalizitions  about debian-users vs ubuntu-users...
[14:02] <cjwatson> enyc: I make nothing in particular of that.
[14:02] <cjwatson> enyc: I'm not going to be drawn into the discussion in general beyond GRUB.
[14:02] <enyc> ok =)
[14:58] <doko> jbicha: brotli test failures on armhf, probably alignment issues
[14:59] <jbicha> doko: fascinating that it works on Debian https://buildd.debian.org/status/package.php?p=brotli
[15:00] <Laney> we're stricter on alignment
[15:01] <doko> jbicha: they run 32bit kernels, we 64bit ones
[15:01] <jbicha> I'm no good on endian/other arch issues so feel free to help out there
[15:32] <bdmurray> xnox: Is the u-r-u task in bug 1749199 still valid?
[15:32] <ubottu> bug 1749199 in ubuntu-release-upgrader (Ubuntu Bionic) "purge conf files on removal of upstart (was session fails to start after an upgrade from xenial to bionic)" [Critical,Triaged] https://launchpad.net/bugs/1749199
[15:44] <enyc> cjwatson: [have saved image files to setup a test/vm later...]
[15:45] <enyc> cjwatson: from what you say,  does update-grub  detecting other distros/multiboot-entries,  work entirely from userspace reading,  no actual "mounting" of other-filesystems to check?
[15:46] <cjwatson> enyc: a lot of that is done by os-prober, which is an external tool
[15:47] <cjwatson> enyc: os-prober tries to use grub-mount where it can, which uses GRUB's filesystem parsing code rather than doing a normal mount, but it does depend a bit on the version of os-prober and on various other details
[16:13] <slangasek> rbasak: when you say you "tagged" 1365874 for us, what do you mean?
[16:16] <rbasak> slangasek: rls-bb-incoming
[16:16] <rbasak> slangasek: sorry, I might have mentioned the wrong one
[16:17] <rbasak> slangasek: it was bug 1601997 I tagged.
[16:17] <ubottu> bug 1601997 in e2fsprogs (Ubuntu) "Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs" [High,Triaged] https://launchpad.net/bugs/1601997
[16:17] <rbasak> slangasek: the other is not really in a triaged state.
[16:17] <rbasak> Though there's a separate request that needs a separate bug that nobody's filed asking for a sync for e2fsprogs.
[16:18] <rbasak> slangasek: following the subsequent discussion with cyphermox above, he suggested that an ubuntu-devel@ thread might be appropriate, so I was going to write one up.
[16:19] <rbasak> slangasek: though if you want to drop the default change by adding a delta, then there's no specific question for the list I think. Really it's just that like enyc said if we don't do anything we'd be making an implicit decision to break compatibility, and that's the part I don't like and would prefer such a decision to be explicit on the ML, bug, release note, etc.
[16:24] <xnox> bdmurray, yes! there is merge proposal too.
[16:24] <xnox> unless merged....
[16:25] <xnox> if i find it
[16:26] <xnox> if i committed it
[16:26] <xnox> if i pushed it
[16:27] <slangasek> rbasak: ok; from my POV, I don't see any reason to be concerned about filesystems created with 18.04 being incompatible with e2fsprogs from older releases by default
[16:30] <xnox> bdmurray, https://code.launchpad.net/~xnox/ubuntu-release-upgrader/lp1749199/+merge/341342
[16:31] <bdmurray> xnox: That should probably go in DistUpgrade.cfg.xenial too
[16:34] <xnox> bdmurray, well... test in bionic first?
[16:35] <xnox> bdmurray, i think i traced this to the right option....
[16:41] <bdmurray> xnox: How do you propose testing it? And the upgrade path from A->B carries the same risk X->B.
[16:51] <xnox> bdmurray, publish bionic-proposed, test upgrade from X->bionic-proposed; if good migrate that to bionic-release.
[16:51] <xnox> bdmurray, rince & repeat same for xenial SRU.
[16:52] <xnox> bdmurray, but i'm not sure how much we care about changing this in upgrades to xenial.
[16:52] <bdmurray> xnox: The release upgrader downloads a tarball for the release to which you are upgrading so no SRU is necessary. Additionally, the upgrade from X->B will read the DistUpgrade.cfg.xenial file.
[16:52] <xnox> and if this goes pear-shaped, i only want to revert/fix-up bionic only; rather than both.
[16:53] <xnox> bdmurray, ok, then i missunderstood the code.
[16:53] <xnox> bdmurray, i thought .xenial file is read in upgrades to xenial (e.g. by trusty)
[16:54] <xnox> i am aware that the target tarball is downloaded. so at the moment i want to change the bionic+ tarball / behaviour only.
[16:59] <coreycb> bdmurray: hi, can you reject horizon 1:2014.1.5-0ubuntu2.2 from the trusty unapproved queue and horizon 2:9.1.2-0ubuntu6 from the xenial unapproved queue?
[16:59] <coreycb> bdmurray: sorry, really need to get in the habit of seeing what's already in the queue before uploading
[17:00] <bdmurray> xnox: The extension is the "from_release" see DistUpgradeConfigParser.py
[17:01] <bdmurray> coreycb: so reject the newer one not the older one?
[17:01] <coreycb> bdmurray: just those specific versions
[17:02] <coreycb> bdmurray: well actually you can also reject horizon 2:9.1.2-0ubuntu5 from xenial as i'll combine that with the new one
[17:06] <coreycb> bdmurray: sorry this one too for trusty: 1:2015.1.4-0ubuntu4
[17:19] <enyc> cjwatson: fwiw, is 32-bit vs 64-bit  OSes likely to make any difference at all  to my  14.04/16.04/18.04  Bios-based multi-boot / ext4-compatibility test I'm going to test-out in a VM later  ??.
[17:25] <cjwatson> enyc: I wouldn't expect so
[20:03] <slangasek> infinity, stgraber: TB meeting?
[21:22]  * hallyn tries to recall....  is feature freeze applicable to universe?
[21:28] <enyc> cjwatson: confirmed, Grub2 14.04 16.04  all happy with 18.04,  but e2fsprogs and kernels still give issues [checking issues there].  TJ- on the case r.e. iscsi host and guest OS..  i'll update bugs when I can, but essentially it doesn't require a grub2/os-prober/etc bug, now actually checked/confirmed!
[21:30] <enyc> cjwatson: thankyou for looking-in/feedback earlier
[21:52] <mwhudson> hallyn: yes
[21:53] <hallyn> k
[21:53] <hallyn> thx
[21:53] <hallyn> wouldve been nice to get tpm-tools up to 3.0.x
[22:16] <xnox> hallyn, hm.... where is that coming from?
[22:16] <xnox> i guess you do not mean https://sourceforge.net/projects/trousers/files/tpm-tools/
[22:16] <xnox> ah https://github.com/tpm2-software/tpm2-tools/releases
[22:46] <hallyn> xnox: yeah - i have it built for artful in ppa:serge-hallyn/tpm
[22:46] <hallyn> (trousers doesn't work with tpm 2.0)
[22:55] <mwhudson> hallyn: FFe's do exist though :)
[22:56] <mwhudson> and are pretty easy to get for universe packages a week after feature freeze begins
[23:18] <hallyn> yeah i'd just do it except i would have to find time for a cleaner fix for the .pc file in tpm2-tss :)
[23:18] <hallyn> if i figure that out i'll pursue ffe.
[23:18] <hallyn> thx