[08:52] <lag> Good morning all
[08:53] <lag> Is there anyone around who can speak about the Ubuntu Installer
[08:53] <lag> I wish to discuss the possibility of adding a feature which selects an appropriate DTS file on boot - should probably be a Grub thing
[08:54] <lag> cjwatson: Are you still Grubbing these days?
[08:55] <cjwatson> lag: I still maintain it in Debian, but I don't maintain the Ubuntu packages any more
[08:56] <lag> cjwatson: It sounds like everything it being moved to Debian anyway
[08:56] <lag> cjwatson: I should say "back into"
[08:56] <lag> cjwatson: Hopefully then upstream *cough* *cough*
[08:56] <lag> cjwatson: ..
[08:56] <cjwatson> lag: I don't think I can talk usefully about DTS stuff though
[08:57] <lag> cjwatson: Do you know if anyone can?
[08:57] <lag> cjwatson: There are some AArch64 platforms which require DTBs in order to boot
[08:57] <cjwatson> lag: Maybe cyphermox or waveform
[08:58] <cjwatson> lag: Or you could simply bring it up directly upstream
[08:58] <lag> cjwatson: I think it's a distro thing - I can't see Grub carrying DTBs
[08:58] <cjwatson> lag: It might not *carry* them, but surely it would need configuration support for them?
[08:59] <lag> cjwatson: It would need to know where (in the Installer) to find them
[08:59] <cjwatson> Anyway, this is the point when I can't usefully say more, sorry
[08:59] <lag> cjwatson: :)
[08:59] <cjwatson> I burned out of doing this stuff in Ubuntu four years ago :P
[08:59] <lag> cjwatson: Thanks for getting back to me anyway
[08:59] <lag> cjwatson: NW - I shall continue with Mathieu and Dave
[10:01] <seb128> sladen: good morning. We got a new ubuntu font version, do you think you would have time to help with the package update (I'm not familiar with the process, is it documented somewhere?). I've opened bug #1819135 with the zip attached there
[10:01] <ubottu> bug 1819135 in fonts-ubuntu (Ubuntu) "Update to 0.84 (includes a new thin version)" [Undecided,New] https://launchpad.net/bugs/1819135
[10:04] <sladen> seb128: this is not a new version in the sense that you or I are used to.  This is a binary dump tossed over the wall, or unclear origin with correspondingly little insight into changes or regression potential.  Perhaps one could ask the provider of the binary blob to expand on its origins
[10:05] <sladen> seb128: (in the meantime, I would plan on extracting only the file 'Ubuntu-Th.ttf', and toss that into the existing package)
[10:08] <seb128> sladen: thx, indeed just adding the new file seems like easier ... should I just do that to start with?
[10:14] <seb128> sladen: how did it work for updates in the past? Did we had those details? Or did we end up just taking the new blob, doing the testing we could do and uploading that?
[10:16] <sladen> seb128: had a script that binary patched a bunch of easily-missed things; then some effort at manually regression-testing via a semi-private repo; the answer has been that the (various) blobs claiming to be '0.84' (or various other numbers) regressed too much in eg. vertical metric, or mono, or such.  (ie. unusable)
[10:17] <sladen> seb128: the Thin shouldn't regress, because it did not exist before
[10:19] <sladen> seb128: looking around at how this was done before   0.84+arabic-0ubuntu1~ppa0    0.91-0ubuntu~prerelease~nonfree   0.84~mono0.83+arabicfontconfig   were various attempts to deal with this in the past
[10:19] <sladen> seb128: in a way that still made things vaguely sane to back out
[10:21] <sladen> seb128: alternative would be  fonts-ubuntu-thin=0.84   as a separate micro-package
[10:23] <seb128> sladen: ok, thx for the input, tricky indeed
[10:23] <seb128> let's start with adding the new ttf then
[10:23] <seb128> thx
[10:27] <sladen> seb128: okay, if the md5 of that .ttf is  aa86b6  then it dates from  2015-10-19
[10:28] <sladen> seb128: and originally Marcus wanted it for just print use within the design team.  Therefore, it is unhinted IIRC
[10:28] <seb128> sladen: yes it is
[10:29] <seb128> so that's why it wasn't included?
[10:31] <sladen> seb128: think so.  (subject to hazy memory).  The reason why it is not in Google Fonts/Google Docs is simpler ... licence != SIL OFL
[10:31] <sladen> seb128: which is a downstream requirement for new files
[10:34] <sladen> seb128: actually, it has hint instructions (though this are ignored anyway, because the autohinter is used instead).  Fire at will, see what happens.  If being conservative, wait until 2019-04-19
[10:34] <seb128> k
[10:36] <sladen> sabdfl: ^^ if you're ready to make a pragmatic re-evaluation on the licence, everything would become a lot easier (Debian, G.Docs, ...)
[10:48] <doko> ginggs: is cuda still requiring GCC 7?
[10:57] <seb128> does anyone understands from update_output.txt what is still needed for poppler to migrate?
[10:59] <Laney> gdal at least
[11:02] <Laney> possibly only that, but hard to tell
[11:11] <seb128> ha, LocutusOfBorg just reuploaded that one
[11:11] <seb128> k, let's see once it's built
[11:19] <LocutusOfBorg> seb128, yes, my intention wasn't to upload gdcm yesterday, it has been a wrong dput... and now osmon is not there so lets fixup
[11:21] <seb128> LocutusOfBorg: thx
[11:25] <LocutusOfBorg> sorry for the mess, nobody took care of finishing the transition for 15 days, and then we all focused on the same package :(
[11:40] <seb128> no problem, it's a lesson to check on the channel with others before starting poking next time :)
[11:45] <ginggs> doko: i think in debian yes, in ubuntu, possibly not - i'll doublecheck
[12:18] <LocutusOfBorg> seb128, the problem is that when I travel on train, my internet sucks, so I download stuff and do it "offline"
[12:19] <LocutusOfBorg> otherwise I might miss a lot of messages
[12:19] <seb128> right, understandable
[12:19] <LocutusOfBorg> sadly looks like the work started between me leaving the office, and me opening my laptop again on train :p :)
[12:19] <LocutusOfBorg> anyhow, gdal is now good, lets see if it migrates in the next run or two
[12:31] <sladen> seb128: think I've found the "sources" for that .ttf  (not that we can rebuild it)
[12:33] <seb128> ah, where is it?
[12:36] <sladen> seb128: ~/.../fonts-for-mpt/2015-10-30_Ubuntu_0.84_documentation_tests_r02/Engineering\ Sources/Ubuntu-Th_source_vtt.ttf  ;-)
[12:37] <seb128> haha
[12:55] <ginggs> doko: cuda 9.2 in debian supports up to gcc 7 / clang 5, 10.0 in ubuntu gcc 7 / clang 6, and 10.1 (newly released) gcc 8 / clang 7
=== ricab is now known as ricab|lunch
[13:36] <ahasenack> doko: do python3 extensions/bindings (aka, they ship .so files) usually have corresponding debian/python3-*.symbols files?
[14:01] <sforshee> LocutusOfBorg: wanted to make sure you saw my comments on bug 1813071, as virtualbox is the last test failure blocking the disco-proposed kernel
[14:02] <ubottu> bug 1813071 in virtualbox (Ubuntu) "virtualbox 5.2.24-dfsg-4build1 ADT test failure with linux 5.0.0-1.2" [Undecided,Confirmed] https://launchpad.net/bugs/1813071
[14:10] <doko> ahasenack: no, that's some samba speciality. I'd say you don't need these just for the support library, not the extension
[14:11] <ahasenack> doko: both the library and the extension had symbols files for python2, I kept doing it for py3
[14:12] <ahasenack> doko: sorry, too many double negatives in your sentence to parse :)
=== ricab|lunch is now known as ricab
[14:53] <LocutusOfBorg> nice sforshee  thanks!
[14:53] <LocutusOfBorg> just to know, did you test both host-guest with that change?
[14:53] <LocutusOfBorg> I'm fine to upload it of course if you tested it
[14:55] <sforshee> no I have not tested, however the change should make no functional difference
[15:02] <xnox> hmmm cannot dput into launchpad
[15:02] <xnox> ftplib just stuck in sendall.....
[15:02] <xnox> is it me, or everyone?
[15:07] <ahasenack> ppa uploads are working for me, if that counts
[15:16] <xnox> that is handled very different to the archive uploads
[15:16] <xnox> however that too hangs for me
[15:16] <xnox> i wonder if my openvpn is dead
[15:16] <xnox> yeah, dead vpn
[15:17] <xnox> everything works now.
[15:26] <teward> um... stupid question, but why is openjdk-11-* in Bionic actually openjdk 10?
[15:26] <Odd_Bloke> tdaitx: ^
[15:26] <teward> I see 11 is actually in proposed, but curious to why the misnaming in Bionic
[15:29] <jbicha> teward: see bug 1814133
[15:29] <ubottu> bug 1814133 in zeroc-ice (Ubuntu) "update to openjdk 11 in 18.04 LTS" [Undecided,New] https://launchpad.net/bugs/1814133
[15:30] <jbicha> and https://lists.ubuntu.com/archives/ubuntu-release/2018-March/004359.html and https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#OpenJDK
[15:32] <teward> jbicha: neither answers why the package names are openjdk-11* in Bionic, which is the last remaining question, I'd have expectedd that to be named openjdk-10-* instead of 11
[15:33] <teward> but that does give insights to some of the headaches
[15:34] <jbicha> we don't want anyone using openjdk-11 in Ubuntu 18.04 once the transition completes
[15:34] <jbicha> that means that you'd have to make the openjdk-11 packages empty transitional packages
[15:35] <jbicha> there are potential upgrade challenges with renaming packages in SRUs
[15:35] <doko> teward: they *are* named 11 in bionic
[15:36] <teward> doko: i think you've misinterpreted my question
[15:36] <teward> doko: my question is why arent they named *10* because that's the version they *are*
[15:36] <teward> but jbicha's answer is valid
[15:36] <jbicha> *10 in my answer :)
[15:36] <lag> cyphermox: waveform: Are you guys up yet
[15:36] <lag> ?
[15:36] <teward> jbicha: got that from the statement, though.
[15:36] <teward> somehow.
[15:36] <teward> (ERR: Not Enough Coffee for me)
[15:44] <tdaitx> teward: what jbicha said is correct, it was done to prevent having openjdk-10 package in bionic main after openjdk-11 transition was completed
[15:44] <tdaitx> https://lists.ubuntu.com/archives/ubuntu-release/2018-March/004364.html
[15:46] <teward> makes sense.
[15:50] <cyphermox> lag: isn't there already flash-kernel and such that deals with the dtb?
[15:50] <waveform> lag, I'm around
[15:50] <lag> cyphermox: waveform: o/
[15:51] <lag> cyphermox: How does it know which DTB to load?
[15:51] <lag> cyphermox: So if I were to take the Ubuntu Installer, plug it into my machine, what are the steps to pick the correct DTB?
[15:52] <cyphermox> what Ubuntu Installer?
[15:54] <cyphermox> I don't know what curtin does for arm64 installs, I would expect that if you can pick the right kernel the kernel package would ship what you need
[15:56] <lag> cyphermox: And flash-kernel is used inside the Ubuntu Installer?
[15:56] <lag> cyphermox: The AArch64 one
[15:57] <lag> cyphermox: I guess it's this one: http://cdimage.ubuntu.com/releases/18.04.2/release/ubuntu-18.04.2-server-arm64.iso
[15:59] <teward> tdaitx: at least it's in bionic-proposed and I have that enabled (with priority 100, so it doesn't install from proposed unless I tell it to), so for *my* needs I can get actual JRE/JDK 11 installed to run some things that need newer JDK (nothing I have installed or used here has any RDeps currently on the openjdk 11 packages that're actually JDK10 that would break, so at least I have that as an advantage)
[16:02] <lag> cyphermox: I don't see any DTBs currently installed in that version of the installer
[16:02] <cyphermox> lag: AFAIK, yes; but exactly how it works I don't know
[16:02] <tdaitx> teward: nice! please let us know if you see runtime failures, bug reports are very welcome =)
[16:03] <cyphermox> lag: the DTBs come from some kernel or firmware package.
[16:04] <cyphermox> dannf: do you know more about this than I do? ^
[16:06] <lag> cyphermox: So the installed kernel inside the Ubuntu Installer needs to be able to boot the platform
[16:06] <lag> cyphermox: That cannot happen without pre-installed DTBs
[16:06] <lag> cyphermox: This is kinda what I'm proposing
[16:06] <dannf> cyphermox: DTBs are provided in the kernel build. to make a generic installer work w/ unflashed dtbs, we'd need to have a way to select (or detect) the platform at grub-time
[16:07] <lag> dannf: Right
[16:07] <dannf> grub can load dtbs w/ the "FDT" option, similar to initrd
[16:07] <cyphermox> indeed.
[16:07] <lag> dannf: You mean "devicetree" option?
[16:07] <dannf> lag: yeah, that
[16:07] <lag> dannf: Right, but these need to be installed *inside* the Ubuntu Installer ISO
[16:08]  * dannf hasn't worked w/ unflashed FDT systems in years, going from memory
[16:08] <lag> dannf: One suggestion would be to have a writeable area inside the ISO
[16:09] <lag> dannf: So once flashed to the {USB,SD} a user could place a DTB inside said partition which Grub could load from
[16:09] <cyphermox> I don't think that's very useful
[16:09] <lag> cyphermox: Happy to hear alternative solutions :)
[16:09] <dannf> lag: oh, are you trying to solve non-upstream dtbs?
[16:09] <cyphermox> I think the best would probably to make use of ubuntu-image to generate the right type of image for you
[16:10] <lag> dannf: Not necessarily
[16:10] <lag> dannf: If we could load all upstream DTBs into the Installer image, that too is workable
[16:11] <cyphermox> lag: I think you should open a bug and clearly describe exactly the problem you want to solve so everyone can be on the same page and look at the same information
[16:12] <lag> cyphermox: I guess I can do that - if you'd prefer to discuss this on LP rather than here
[16:13] <cyphermox> it's that here it's confusing, especially if we need to have input from other people
[16:13] <cyphermox> whereas on a bug, we have a written track of what the problem is, etc.
[16:13] <cyphermox> from there it's easier to assign work to people as appropriate.
[16:15] <dannf> lag: i think we have udebs already w/ the upstream dtbs - we needed that for our early x-gene support
[16:16] <dannf> lag: but +1 what cyphermox says - one issue is that we're moving to subiquity, and all my experience is with d-i. hopefully whatever the answer is would have the same user experience though
[16:17] <lag> dannf: That's fine - I'll write something up on Monday
[20:16] <vorlon> Trevinho: why does this unity SRU involve a rename (and possible code changes) of tools/migration-scripts/07_unity_migrate_gnome_favorites_v2 to tools/migration-scripts/07_unity_migrate_gnome_favorites_v3 ?
[20:59] <Trevinho> vorlon: mhmh, for what distro?
[20:59] <vorlon> Trevinho: cosmic
[20:59] <Trevinho> vorlon: mh I don't see the diff in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3655/2019-03-04_11:03:56/cosmic_unity_content.diff
[21:00] <vorlon> Trevinho: that's because I diffed against bionic instead of cosmic, heh
[21:00] <Trevinho> :)
[21:00] <vorlon> see, bileto + syncs are bad for the SRU process
[21:01] <Trevinho> vorlon: you can use the bileto generated ones, should be the quickest and safest way
[21:01] <vorlon> Trevinho: not integrated in the workflow
[21:01] <Trevinho> vorlon: it's 2 click aways...
[21:01] <Trevinho> I know :)
[21:01] <Trevinho> but well, not sooo complicated.
[21:01] <vorlon> Trevinho: it's 2 clicks away from a page that is also not integrated in the workflow :P
[21:01] <vorlon> SRU processing is commandline-driven
[21:01] <Trevinho> I can imagine... Well, I didn't design this :)
[21:02] <vorlon> you don't have to use bileto
[21:02] <Trevinho> that's why sometimes we just do a copy from ppa to proposed, but since I've not such powers, I tend to do this not to bother others.
[21:03] <Trevinho> although I'm not the only, one using it for SRUs, so since isn't really dead yet, maybe would be nice to integrate it a bit into the tools, I've not clude how hard it could be, but since diffs are there, probably it could be done quite easilty.
[21:05] <Trevinho> as I understand both you guys and who is using it, being quite conveinent when there are merge proposals that you can land in few clicks instead of having through the manual packaging part
[21:08] <vorlon> Trevinho: lp:ubuntu-archive-tools and patches welcome; otherwise bileto's behavior continues to be a wart that the SRU team will discourage
[21:08] <Trevinho> I was already on that xD
[21:11] <bdmurray> does anybody have access to bug 871007?
[21:11] <ubottu> Error: Launchpad bug 871007 could not be found
[21:11] <bdmurray> sarnold: maybe you?
[21:14] <bdmurray> oh, right its Friday
[22:25] <Odd_Bloke> bdmurray: Can't print on Tuesdays, can't see bug 871007 on Fridays?
[22:25] <ubottu> Error: Launchpad bug 871007 could not be found
[22:30] <bdmurray> Odd_Bloke: I was remembering that Seth is out today.
[22:44] <bdmurray> xnox: vorlon said you might have some insight into ubuntu-release-upgrader-gtk no depending on python3 as it should https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/debian/control . python3-distupgrade has the right thing.
[22:48] <vorlon> bdmurray: I think this is the recent package where I was dealing with this https://lists.ubuntu.com/archives/disco-changes/2019-February/007613.html
[22:51] <Trevinho> vorlon: https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193
[22:52] <bdmurray> Trevinho: That merge gets the diff from bileto?
[22:53] <Trevinho> bdmurray: yep
[22:53] <Trevinho> try with ./sru-review indicator-application
[22:53] <bdmurray> I think infinity had some concerns with the trustworthiness of bileto for the diff.
[22:54] <Trevinho> well... you know, if you really don't trust it... can still check manually.
[22:54] <Trevinho> but at least it gives you something
[22:54] <Trevinho> if you really want we can still download the srcs again locally and do the debdiffing, but ...
[22:55] <Trevinho> bdmurray: what was the concern for?
[22:56] <Trevinho> in any case we couldn't use the one from the ppa, since there might multiple revisions in there...
[22:58] <bdmurray> Trevinho: I'm not certian maybe because he hasn't audited bileto's code?
[22:59] <Trevinho> could be... well, again the only other option is to download the sources and do the debdiff locally to show, whatever is fine, but since SRUs are still coming on that, spending another hour on it isn't too bad