/srv/irclogs.ubuntu.com/2018/03/13/#ubuntu-devel.txt

mwhudsontsimonq2: congrats00:55
darkxstbdmurray 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
ubottubug 1751546 in tasksel (Ubuntu) "the net installer doesn't install gnome-vanilla" [High,Triaged] https://launchpad.net/bugs/175154608:08
infinitydarkxst: See my follow up.08:14
cpaelzerwhen I run the same gcc command on Debian and Ubuntu where does the collect2 gets its args from08:17
cpaelzerThey differ in my case between Debian and Ubuntu causing an issue (for Debian) that I want to resolve/understand08:17
cpaelzerI moved to the gcc-7 in our proposed so both are 7.3.0-11 based08:18
infinitycpaelzer: From the gcc spec and/or build options.08:18
cpaelzerI thought I compared the gcc -v and other parts of a verbose build08:18
infinitycpaelzer: gcc -dumpspecs will give you a (messy) view of that world.08:18
cpaelzerinfinity: can I let gcc list the build in defaults?08:19
cpaelzerlet me check that infinity08:19
* cpaelzer goes messy08:19
infinitycpaelzer: 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:19
cpaelzerinfinity: I08:20
cpaelzerI'm already down toa simple commandline gcc call08:20
cpaelzerbehaving differently08:20
cpaelzerand the dumpspec seems to prove that08:20
cpaelzerI found what I assume to be the difference08:20
cpaelzerUbuntu has in the *link step "... --hash-style=gnu   --as-needed   %{shared:-shared} ..." while debian lacks the --as-needed in the same08:21
infinitycpaelzer: Oh, yes.  We've been using as-needed for ages.08:21
infinitycpaelzer: Have you really never tripped on that before today? :)08:21
cpaelzerI tripped over it about 5 times I think08:22
cpaelzerbut not that Debian started to differ, because it didn't a while ago08:22
infinitycpaelzer: 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
infinitycpaelzer: command-line order matters with as-needed because deps are searched left to right.08:22
infinitycpaelzer: 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
cpaelzerinteresting08:23
cpaelzerinfinity: I actually fixed it in the build system of the package a year or so ago08:23
cpaelzerbut our dep8 test needs all that fixed up as well now08:23
cpaelzerinfinity: thanks for the right pointers08:23
* cpaelzer need to check old debian test logs ...08:24
cpaelzeryep, you are right (as always) the difference was there in the past as well08:24
cpaelzerit just now became an issue due to other changes08:25
cpaelzerperfect, I think I can work this out now08:25
infinitycpaelzer: 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:28
infinityWe should probably reopen that discussion with Debian too, so we don't trip on the bugs first. :/08:29
cpaelzerinfinity: 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 this08:31
cpaelzerI 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 anyway08:31
cpaelzerneeds some checks if it works as I plan it atm08:31
mwhudsonwait --as-needed isn't the default always and forever?08:32
infinitycpaelzer: Well, fixing the gcc call is likely trivial too.08:32
mwhudsontil08:32
infinitycpaelzer: 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:33
infinitycpaelzer: 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
darkxstinfinity, 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 package08:34
darkxstkeep them happy08:34
infinitydarkxst: I suspect that 50% is rather high.  Most people don't actually care that deeply about such details.08:35
infinitydarkxst: (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:35
cpaelzerinfinity: 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
infinitydarkxst: 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
cpaelzerinfinity: it works to build on both, but it increases the things linked and we checked on some of that08:36
cpaelzerthat is why I mean I want to fix mostly the test08:37
darkxstinfinity, 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!08:38
=== LtWorf_ is now known as LtWorf
darkxstinfinity, if its made into just another generic task, how do we avoid it getting lost in the sea of generic tasks?08:40
infinitydarkxst: s/task/package/?08:41
infinitydarkxst: 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
darkxstalso it still has upload rights attached to the packageset, which the DMB are proposing to expand in order to get rid of desktop-extra08:41
infinitydarkxst: From my POV, it's better to have it difficult enough to find that the picky people have to know where to look.08:42
darkxstinfinity, 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 session08:50
infinitydarkxst: I mean, sure.  Maybe that's true.  But on the flipside, the supported upgrade path for Ubuntu GNOME is to Ubuntu.08:51
infinitydarkxst: ubuntu-gnome-desktop depends on ubuntu-desktop, and the release-upgrader makes that same assumption.08:51
infinitydarkxst: So vanilla-gnome-desktop is very much a "weird power user" thing, just like any other vanilla DE experience.08:52
infinitydarkxst: 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:53
darkxstinfinity, ok I will change tasksel to use package instead08:59
juliankI 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:03
darkxstjuliank, there might still be some overrides in there that are now redundant, with Ubuntu switching to gnome-shell09:12
juliankDid USB audio break recently? I see my DAC just fine in alsa, but PulseAudio does not detect any sink on it...09:13
juliankexternal mic is broken too09:15
cpaelzeris there a best practise what set of ruby triggers to add on autopkgtests that fail due to the ongoing transition?09:50
* cpaelzer goes lazy and tries locally with all proposed09:53
cpaelzerbdrung: any time to updates on bug 1753938?10:03
ubottubug 1753938 in qemu (Ubuntu) "slirp: domainname and classic stateless for DHCP" [Undecided,New] https://launchpad.net/bugs/175393810:03
cpaelzerhow is upstreaming the changes going atm?10:03
dokogcc-6 demoted \o/10:11
cpaelzergz doko!10:15
tsimonq2mwhudson: thanks11:21
=== ginggs_ is now known as ginggs
enycSomebody being assigned to  1601997 1365874  for 18.04 ?12:05
rbasakbug 160199712:08
ubottubug 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/160199712:08
=== mhcerri_ is now known as mhcerri
enycrbasak: thats the killer,  1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too...  tytso himself encourages!12:10
enycSecondarially, 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:11
rbasakTo 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
rbasakcyphermox perhaps? ^12:12
enycsome verison can't even mount12:12
enycin any case its' a very annoying needless compatibility problem12:12
rbasakBut it looks like Debian have no intention of putting that into stable.12:12
rbasakSeems like a relatively trivial FFe to undo.12:12
rbasak(some theoretical risk of installer regression but seems unlikely to me)12:13
enycrbasak: undo the extra feature?12:13
enyc[put back mke2fs.conf from older e2fsprogs, specifically]12:13
rbasakYep12:13
rbasakSeems reasonable to me, but someone closer to the installer packages should decide12:14
rbasakOr the release team.12:14
enychowever, on the FFE front, tytso also reccomends we strongly consider e2fsprogs upgrade to 1.44  (though this is separate matter)12:14
enycwould like support for some (non-default, but useful for some) flags  included from the outset in LTS12:14
rbasakenyc: do you have references for that recommendation specifically please?12:15
enycrbasak: "1365874 wrt e2fsprogs freeze-exception for 18.04 worthy too..."12:15
rbasakBug 1365874 seems unrelated to bumping to 1.44 to me.12:16
ubottubug 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/136587412:16
enycrbasak: read comemnts, i check12:16
enycSee comment #17 onwards12:17
enyci can see now there maybe should be many different bugs ;p12:17
rbasakI see thanks.12:17
rbasakslangasek, gaughen: ^ worth taking a look IMHO (not recommending we do it, just that it's worth considering).12:19
enycNB:   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:19
enycI have not yet found/created a bug about 412:20
rbasakslangasek, 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/1712:20
ubottuLaunchpad 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
rbasakenyc: thank you for drawing attention to this.12:20
rbasakenyc: backporting is much harder process-wise because of the risk of regressing users of stable releases.12:20
rbasakenyc: but that can be quite separate as it doesn't have a deadline like Bionic does.12:21
enycrbasak: 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:21
rbasakIMHO 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
enycrbasak: nodsnods12:22
enycso 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:22
enycthankyou for understanding and being interested to make "informed choices"[!]12:23
jbichajuliank: 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
jbicharan out of time this cycle12:29
cyphermoxrbasak: if you're talking about an e2fsprogs FFe, up to you12:48
cyphermoxI'm fine with a backport of e2fsprogs, but this sounds like it has nothing to do with an "installer bug"12:51
enycI 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
cyphermoxno, that's not the point.12:51
cyphermoxthere are two options: either add metadata_csum to old releases by backporting, or reverting everywhere12:52
cyphermoxit's orthogonal to having a newer e2fsprogs in 18.04.12:53
enycI noted in bug, canonical partners may have views, onther non-ubunut-systems they support/interoperate w too.12:53
enyccyphermox: sure inded, but both (1) (2) go in same package/change/FFE12:53
enycbackports complex SRU process apparently12:54
rbasakcyphermox: 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:54
cyphermoxenyc: my point is, you're mising up different processes12:55
rbasakcyphermox: and separately, should we sync e2fsprogs to get the newer upstream release (which is a mostly unrelated question)?12:55
cyphermoxrbasak: I value filesystem integrity. My opinion is that we should keep it on if possible, especially looking forward12:55
enyctytso 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-community12:56
cyphermoxrbasak: re: newer upstream, I'd say it missed the mark?12:56
rbasakcyphermox: 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:56
cyphermoxrbasak: tbh, I'd backport it, if the kernel in xenial-release supports it.12:57
rbasakSince my ping, it occurred to me that perhaps messing with filesystems across different releases is a more server-y use case.12:58
rbasakI'll see what my team thinks.12:58
enycthink about dual-booters users...12:58
enyci've had many cases of older relase, wanting to rewrite/upgrade grub12:58
enycwhich then BREAKS the newer release booting12:58
rbasakcyphermox: 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
enycunless you go out of your way to  dpkg-reconfigure grub2  and tell it NOT to install grub any more12:58
cyphermoxrbasak: sure12:59
cyphermoxenyc: have you filed bugs about it?12:59
enycrbasak: 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.12:59
cyphermoxrbasak: well, this would be a question for not just the server team, perhaps to bring up on ubuntu-devel@13:00
enyccyphermox: 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
cyphermoxrbasak: arguably you're just making sure e2fsprogs supports the feature, it could be "off by default" in the backport.13:00
enyccyphermox: YES thats a godo risk-managed approach13:01
rbasakAgreed (to both)13:01
enycnot everybody will install/have the backports, etc etc.  theres' little-adavantage to the feature, so.13:01
cyphermoxenyc: if you're written about a grub issue in the e2fsprogs bug, it's been missed13:01
enyccyphermox: menitoned in there13:01
rbasakThere's the separate question of whether the older kernel will mount it. Do we know?13:01
enycrbasak: from what i can see, trusty requires HWE kernel, xenial doesn't (i.e. 4.4 is ok)13:02
cyphermoxenyc: 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
enycrbasak: but don't forget about other distros people use about,  its not an ubuntu-only world13:02
rbasakenyc: that doesn't sound too bad. Thanks.13:02
cyphermoxrbasak: not sure13:02
cyphermoxtbh, I wouldn't backport to trusty?13:02
cyphermoxhrm13:03
enyccyphermox: 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
cyphermoxotoh you "could", and depends on the hwe kernel then13:03
enyccyphermox: tytso had comments on that to..  I must stress reading ALL commends on both bugs.13:03
enycwill do13:03
enycthankyou for starting to think, i know its complex13:03
cjwatsonIf there's a grub change required in older releases, it should be a small cherry-pick, not a full backport13:03
rbasakImagine 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
cjwatsonWe normally use the term "backport" for backporting full new releases, rather than cherry-picking individual commits13:04
rbasakIf we were to pick the middle option, then not backporting to Trusty would be reasonable.13:04
enyccjwatson: 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
enycrbasak: agreed13:04
cyphermoxrbasak: there's prior art saying it's "supported", at least to some degree13:06
rbasakOK.13:06
cyphermoxthat said, now I think we should backport to trusty too if we do it at all13:06
cyphermoxthe metadata_csum change looks to have been made in yakkety13:07
enycIMHO 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
rbasakAnd 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
cjwatsonenyc: 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:07
rbasak(my middle option is technically possible but seems too surprising to users to me to want it)13:08
cyphermoxrbasak: scratch the installer out of that, it's not the issue -- it will just use whatever is default13:08
enyccjwatson: 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
rbasakYep13:08
enyccjwatson: there is some other grub devel messages about realizing they can just ignore metadata_csum entirely, and not sure when that was commited.13:08
cjwatsonenyc: I think you are mistaken.13:09
cjwatsonOr possibly confusing something.13:09
cjwatsonThere's the metadata_csum thread which I started; I don't think anything has been committed for that yet13:09
cjwatsonBut that's metadata_csum_seed13:10
enyccjwatson: 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
cjwatsonWhich I don't think is what you're talking about here.13:10
enyccjwatson: indeed not, csum_seed is another matter13:11
cjwatsonThere were no other relevant changes since 2.02~beta2.13:11
cjwatson(regarding either of the features you mention)13:11
enyccjwatson: 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
enycwhich is in part why not posted bug baout that (4) aspect yet13:12
cjwatsonYour anecdotes, my checking the git history ... hmm, I wonder which is more accurate :)13:12
enycand what change is marked properly in git13:12
enychas some other change, fixed a bug that stopped that case working?13:13
enyci don't know13:13
cjwatsonThe number of changes to the ext2 driver in GRUB is very small13:13
enychttps://www.linuxquestions.org/questions/slackware-14/install-grub2-on-current-failed-4175580346/13:13
enycI'm well aware that area is uncertain and would need cecking/testing for bug to be raised w/ clear facts.13:14
enycGiven 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:15
cjwatsonAll 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:18
cyphermoxenyc: have you opened that separate bug report for the grub issues you're seeing?13:19
cjwatsonFilesystem 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:19
bigonhttps://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
ubottuLaunchpad bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [Undecided,In progress]13:23
ubottuLaunchpad bug 1754896 in libnative-platform-java (Ubuntu) "Sync libnative-platform-java 0.14-3 (universe) from Debian unstable (main)" [Wishlist,Confirmed]13:23
cyphermoxbigon: I don't think so, looks all bugfixy13:27
cyphermoxtdaitx_: opinions? ^13:29
tdaitx_cyphermox: bigon: seem all clear, maybe we should bump LP: #1754896 from whishlist to high as it would fix LP: #1683761 for bionic13:37
ubottuLaunchpad 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/175489613:37
ubottuLaunchpad bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [Undecided,In progress] https://launchpad.net/bugs/168376113:37
enyccyphermox: 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:38
cyphermoxenyc: ok13:39
enyccjwatson: noted!  your investigations, suspect that grub2 back to xenial (only?)  what about trusty,  ought to be compatible with 64bit,metadata_csum ?13:39
enycone 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
cyphermoxbigon: tdaitx_: cool. I will sponsor that then13:40
tdaitx_tks ;-)13:40
=== tdaitx_ is now known as tdaitx
cjwatsonenyc: Your guess about my investigations is wrong; I checked back to 2.02~beta2, which is in trusty.13:45
enyccjwatson: i asked you "what about" and a (?) in there, i did not 'guess'13:46
enyccjwatson: so, your investigahions suspect both should be ok13:46
enycacid-test is to bios-mode install a 14.04, and a 18.04-test dual-boot, then update-grub on the 14.0413:47
cjwatsonenyc: "suspect" = "guess" :-)13:47
cjwatsonenyc: I currently see no reason why trusty's GRUB would be incompatible with 64bit,metadata_csum13:47
cjwatsonenyc: You can also just use grub-fstest from 14.04's GRUB packages (would probably even be doable in a chroot)13:48
cjwatsonenyc: Or indeed grub-probe13:48
enyccjwatson: 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
cjwatsonenyc: Basically all GRUB's filesystem code can be run from userspace13:48
cjwatsonenyc: Sure, but in that case 16.04 would be incompatible too.13:49
enyccjwatson: yes, assuming any other "seemingly unrelated" chainge doesn't affect it.  acid-test should prefer the older-version.13:49
enycnoted13:49
enyccjwatson: thankyou for the pointer abou grub-probe grub-fstest ...13:50
cjwatsonBet you a tenner such a seemingly unrelated change doesn't exist. :-)13:53
enychaha13: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
enycsure !13:53
cjwatsonI think it's much more likely that confusion is caused by *different ext[234] features*.13:54
enychowso? e.g. the _csum or something else?13:54
cjwatsonThat linuxquestions thread you posted had a bunch of changes in mke2fs.conf.13:54
enycright yes13:54
cjwatsonSo I'm suggesting it's more likely that one of those relates to one of the *known* changes since 2.02~beta2.13:55
enycuseful feedback, still worthy of test hopefguly this evening,  so I can then post grub2 backport bug as relevant13:55
cjwatsonAnd that this is probably entirely unrelated to proposed changes in Ubuntu 18.04.13:55
cjwatsonNot backport, please.13:55
cjwatsonCherry-pick, *if anything*.13:55
enycright i see13:55
cjwatsonSaying "backport" invokes quite the wrong set of processes.13:55
enycyes i mean  "grub2 needs fixing for compatibility, heres why, heres where it goes wrong"13:55
enycagreed13:55
enycwhereas, e2fsprogs-wise,  tytso reccomends backport  interestingly.13:56
cjwatsonUpstreams nearly always do.13:58
cjwatsonWe don't always agree :)13:58
enycnodsnods13:58
enycyes i was wondering something along those lines13:58
enyccjwatson: 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
enycwe've ended up with 'decision by default' sofar14:01
enyci guess he's also being conservative...   i don't know about  generalizitions  about debian-users vs ubuntu-users...14:01
cjwatsonenyc: I make nothing in particular of that.14:02
cjwatsonenyc: I'm not going to be drawn into the discussion in general beyond GRUB.14:02
enycok =)14:02
dokojbicha: brotli test failures on armhf, probably alignment issues14:58
jbichadoko: fascinating that it works on Debian https://buildd.debian.org/status/package.php?p=brotli14:59
Laneywe're stricter on alignment15:00
dokojbicha: they run 32bit kernels, we 64bit ones15:01
jbichaI'm no good on endian/other arch issues so feel free to help out there15:01
bdmurrayxnox: Is the u-r-u task in bug 1749199 still valid?15:32
ubottubug 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/174919915:32
enyccjwatson: [have saved image files to setup a test/vm later...]15:44
enyccjwatson: 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:45
cjwatsonenyc: a lot of that is done by os-prober, which is an external tool15:46
cjwatsonenyc: 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 details15:47
slangasekrbasak: when you say you "tagged" 1365874 for us, what do you mean?16:13
rbasakslangasek: rls-bb-incoming16:16
rbasakslangasek: sorry, I might have mentioned the wrong one16:16
rbasakslangasek: it was bug 1601997 I tagged.16:17
ubottubug 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/160199716:17
rbasakslangasek: the other is not really in a triaged state.16:17
rbasakThough there's a separate request that needs a separate bug that nobody's filed asking for a sync for e2fsprogs.16:17
rbasakslangasek: 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:18
rbasakslangasek: 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:19
xnoxbdmurray, yes! there is merge proposal too.16:24
xnoxunless merged....16:24
xnoxif i find it16:25
xnoxif i committed it16:26
xnoxif i pushed it16:26
slangasekrbasak: 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 default16:27
xnoxbdmurray, https://code.launchpad.net/~xnox/ubuntu-release-upgrader/lp1749199/+merge/34134216:30
bdmurrayxnox: That should probably go in DistUpgrade.cfg.xenial too16:31
xnoxbdmurray, well... test in bionic first?16:34
xnoxbdmurray, i think i traced this to the right option....16:35
bdmurrayxnox: How do you propose testing it? And the upgrade path from A->B carries the same risk X->B.16:41
xnoxbdmurray, publish bionic-proposed, test upgrade from X->bionic-proposed; if good migrate that to bionic-release.16:51
xnoxbdmurray, rince & repeat same for xenial SRU.16:51
xnoxbdmurray, but i'm not sure how much we care about changing this in upgrades to xenial.16:52
bdmurrayxnox: 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
xnoxand if this goes pear-shaped, i only want to revert/fix-up bionic only; rather than both.16:52
xnoxbdmurray, ok, then i missunderstood the code.16:53
xnoxbdmurray, i thought .xenial file is read in upgrades to xenial (e.g. by trusty)16:53
xnoxi am aware that the target tarball is downloaded. so at the moment i want to change the bionic+ tarball / behaviour only.16:54
coreycbbdmurray: 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
coreycbbdmurray: sorry, really need to get in the habit of seeing what's already in the queue before uploading16:59
bdmurrayxnox: The extension is the "from_release" see DistUpgradeConfigParser.py17:00
bdmurraycoreycb: so reject the newer one not the older one?17:01
coreycbbdmurray: just those specific versions17:01
coreycbbdmurray: well actually you can also reject horizon 2:9.1.2-0ubuntu5 from xenial as i'll combine that with the new one17:02
coreycbbdmurray: sorry this one too for trusty: 1:2015.1.4-0ubuntu417:06
enyccjwatson: 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:19
cjwatsonenyc: I wouldn't expect so17:25
slangasekinfinity, stgraber: TB meeting?20:03
* hallyn tries to recall.... is feature freeze applicable to universe?21:22
enyccjwatson: 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:28
enyccjwatson: thankyou for looking-in/feedback earlier21:30
mwhudsonhallyn: yes21:52
hallynk21:53
hallynthx21:53
hallynwouldve been nice to get tpm-tools up to 3.0.x21:53
xnoxhallyn, hm.... where is that coming from?22:16
xnoxi guess you do not mean https://sourceforge.net/projects/trousers/files/tpm-tools/22:16
xnoxah https://github.com/tpm2-software/tpm2-tools/releases22:16
hallynxnox: yeah - i have it built for artful in ppa:serge-hallyn/tpm22:46
hallyn(trousers doesn't work with tpm 2.0)22:46
mwhudsonhallyn: FFe's do exist though :)22:55
mwhudsonand are pretty easy to get for universe packages a week after feature freeze begins22:56
hallynyeah 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
hallynif i figure that out i'll pursue ffe.23:18
hallynthx23:18

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