[03:57] <pitti> apw: ack, I filed bug 1510362 about it for nwo
[03:57] <pitti> Good morning
[07:59] <dholbach> good morning
[08:02] <seb128> hey dholbach
[08:04] <dholbach> salut seb128
[11:13] <melodie> hi
[11:14] <sladen> hello melodie
[11:14] <melodie> hi sladen
[11:14] <sladen> just ask your question so that everyone can see it at the same time
[11:16] <melodie> I have a question about the content of ISO, because I want to improve Bento Openbox Remix build. The question is about pool/dist and about EFI or any added package such as drivers for specific hardware, and so on: how does the system know if it has to choose a package in the pool directory? Does it work just by "magic hardware detection" and some pipes between it and apt?
[11:16] <melodie> I hope my question does not sound too dumb, as I really don't have a clear idea about that sphere of processes
[11:19] <melodie> sladen do you think anyone here will have a doc to point me to, or insights they can provide?
[11:19] <sladen> asking questions is never dumb
[11:19] <melodie> thanks :D
[11:19] <sladen> however I'm still trying to work out if /I/ understand the question correctly, in order to be able to answer it or point you towards somebody who might know
[11:20] <sladen> melodie: have you got an example of package that might/might not be chosen, and which you have in mind?
[11:21] <sladen> melodie: eg. are you thinking of something like an Nvidia graphics driver, or a USB modem driver?
[11:21] <sladen> melodie: ideally all hardware should do something useful/sensible when plugged in, and it's a bug if it doesn't
[11:21] <melodie> yes, first idea is about efibootmgr
[11:22] <sladen> melodie: but remixes are normally more about remixing the user applications/desktop environments/languages rather than hardware support
[11:22] <melodie> I aim to bring Bento Openbox Remix to a tech level as close as possible to what is provided by the official versions
[11:23] <melodie> I do it starting from "outside", and will dive into the tech deeper and deeper as time goes
[11:23] <melodie> 2012: the remix is LTS and works (done with Ubuntu Builder)
[11:24] <melodie> 2014 started working on the Trusty LTS (still the same tool but is not dev anymore, and someone shows me the seeds, however my configs aren't packaged so I have to be patient)
[11:24] <sladen> I think vaillant used to be one of the developers of Ubuntu Builder
[11:24] <melodie> now I start using Customizer instead of Ubuntu-Builder, but I want to master the "pool/dist" area, which I haven't so far. next I'll see if I can learn packaging the user prefs
[11:25] <sergiusens> cjwatson, hey, is that "y-series" for destination series I see on launchpad's copy packages interface expected?
[11:25] <melodie> never mind Ubuntu Builder, it's over. Customizer works and while the project continues to provide recent ISO's it's alive. Between versions I want to learn to make it better
[11:26] <cjwatson> sergiusens: yes, you won't actually be able to copy to it because it's marked Future but the series exists
[11:26] <cjwatson> sergiusens: though maybe the copy target vocabulary should filter it out, file a bug
[11:27] <melodie> sladen when I'll handle  pool/dist and be able to package the parts that still need to be packaged, I'll do a meta-package, a session and see if I can start using real seeds.
[11:27] <sergiusens> cjwatson, sure thing, thanks
[11:28] <melodie> sladen so in the case of efibootmgr package, and knowing there is also the BOOT/EFI/ directory in the 64bits isos, how does that work under the hood? would you know that,
[11:28] <melodie> ?
[11:29] <sladen> FourDollars: ^^think you might have been the last person to touch efibootmgr (since then it's been a straight import from Debian)
[11:30] <FourDollars> sladen: yes?
[11:30] <melodie> sladen oh!
[11:30] <melodie> hi FourDollars
[11:30] <FourDollars> Hi melodie
[11:31] <melodie> this is about my noobs questions related to how pool/dist and other additions such as BOOT/EFI/* are "seen" and used in the 64bits ISOs (or other pool packages seen but the hardware recognition tools)
[11:31] <melodie> I'd like to understand how all this is processed during the start of the live and or after it's started
[11:34] <sladen> melodie: I don't know boot stuff well anymore; but I should imagine that locating packages comes a lot later than the early stages of boot.  So they seem to be going in different directions
[11:34] <FourDollars> The files under BOOT/EFI/* can be downloaded from some url. Let me search for it.
[11:35] <sladen> melodie: EFI->Grub->Kernel->initramfs->rootfs->...->Debian-installer (or any particular GUI font end for it)
[11:36] <melodie> sladen where "EFI →" is the EFI in the "BIOS / EFI" computer?
[11:36] <melodie> that would be "EFI → Grub-EFI" ?
[11:36] <FourDollars>  /EFI/BOOT/BOOTx64.efi is defined by the UEFI spec. for 64 bits UEFI BIOS.
[11:37] <melodie> FourDollars I read you
[11:37] <FourDollars> Read it from http://www.uefi.org/specifications
[11:38] <FourDollars>  /EFI/BOOT/BOOTx64.efi will bring up the GRUB and then GRUB will bring up the Linux kernel and initramfs.
[11:40] <melodie> how does the "system" (what part of it?) acknowledges the /EFI/BOOT/BOOTx64.EFI|grubx64.efi presence?
[11:40] <melodie> FourDollars I try to understand how the "magic" works there
[11:40] <FourDollars> That is what UEFI BIOS does.
[11:41] <sladen> melodie: the EFI firmware looks through the available boot devices, and looks if any of the available boot devices contains a file called '/EFI/BOOT/BOOTx64.EFI', loads it into memory, and runs it
[11:41] <FourDollars> melodie: UEFI BIOS will try all boot entries in NVRAM and then search for some pre-defined files.
[11:42] <FourDollars> melodie: There is no magic and they are documented at http://www.uefi.org/specifications.
[11:42] <melodie> sladen oh ok!
[11:43] <melodie> FourDollars ok, some reading to do, thanks
[11:43] <FourDollars> melodie: no problem
[11:45] <melodie> if you have insights for me, about how that works for other packages in pool in the ISOS? I have browsed through the pool of several Ubuntu official flavors and noticed they don't necessarily contain the same packages, which means the devs did different choices (not fixed by an Ubuntu convention for instance)
[11:45] <FourDollars> melodie: BTW, the efibootmgr only edits some variables in NVRAM as I know.
[11:46] <melodie> FourDollars I don't know about that, it's deeped (lower/closer to the hardwareà that I have learned about.
[11:47] <melodie> FourDollars I just browsed my favorite computer dictionnary to read about NVRAM : that's the firmware, right?
[11:47] <melodie> deeped/deeper* (sorry for the typo)
[11:47] <sladen> melodie: one (shouldn't) need to worry about EFI when remixing
[11:48] <FourDollars> melodie: http://archive.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/current/images/cdrom/debian-cd_info.tar.gz
[11:48] <melodie> sladen I use Ubuntu Mini Remix to build on it, which means there is no EFI nor pool/dist at the beginning
[11:48] <melodie> FourDollars I look
[11:48] <TJ-> melodie: UEFI boot from removable media expects to find the Simple Media Boot Path, which means an EFI System Partition with the boot-loader at /EFI/BOOT/BOOT${ARCH}.EFI
[11:49] <melodie> FourDollars that's the sources?
[11:50] <sladen> melodie: Grub
[11:50] <FourDollars> melodie: The files under /EFI/BOOT/ such as BOOTx64.efi is in ./grub/efi.img in  http://archive.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/current/images/cdrom/debian-cd_info.tar.gz.
[11:50] <melodie> TJ- yes, ok I get this. (I have installed only on two machines having UEFI so far, and learned that side of the story)
[11:50] <FourDollars> s/is/are/
[11:51] <TJ-> melodie: OK, I only just came in. Was there some other aspect to the info you are looking for?
[11:51] <melodie> TJ yes, about the packages in pool/dist : what process makes them either chosen or ignored, depending on the hardware where the live boots?
[11:52] <sladen> melodie: are you wondering about different architectures (x86 vs amd64)
[11:52] <melodie> FourDollars I would not know yet how to use the link you just gave me, apart from looking what it contains (but I'll learn that later when the time comes, now I just try to understand the mechanics)
[11:52] <TJ-> melodie: Do you mean, for an ISO image which has package A in its /pool/ already, what makes the installer (d-i/ubiquity) install that package, or do you mean what controls the packages actually included in the /pool/ at CD image creation time?
[11:53] <melodie> sladen no, I guess 32bits don't have UEFI?
[11:53] <FourDollars> melodie: OK
[11:53] <TJ-> melodie: there is 32-bit UEFI too
[11:54] <melodie> TJ- " what makes the installer (d-i/ubiquity) install that package" and if you explain me what controls the package installed in the pool at CD image creation time, I'll just ask you if the info in that doc is enough for me to get the anwser?  →
[11:55] <melodie> https://help.ubuntu.com/community/InstallCDCustomization#Modify_pool_structure_to_include_more_packages
[11:55] <melodie> TJ- ah!
[11:55] <TJ-> melodie: The installed image, including packages, is generally controlled by a preseed file
[11:55] <melodie> 32 bit uefi...
[11:56] <TJ-> melodie: the preseed file is generally included on the kernel command-line at boot-time, by the boot-manager
[11:56] <melodie> TJ- ok preseed, the last thing I'll need to worry about, once I will have created packages for everything, which I haven't yet
[11:59] <melodie> I'll do some tests with the command lines included in that part https://help.ubuntu.com/community/InstallCDCustomization#Modify_pool_structure_to_include_more_packages
[12:00] <FourDollars> melodie: The live system is bought up by casper. You can see boot=casper in the kernel parameter.
[12:01] <melodie> FourDollars yes!
[12:01] <FourDollars> melodie: It is very helpful to extract initrd.lz and read what it is doing.
[12:01] <FourDollars> s/extract/decompress/
[12:01] <melodie> some time I'll ask to be explained the different contents in /usr/share/casper, for now all I know is that some scripts are to be considered and or added in the casper/bottom section.
[12:02] <melodie> FourDollars initrd.lz needs to be renamed to be extracted, right?
[12:02] <melodie> to .gz then gunzip?
[12:02] <TJ-> melodie: best thing is to read the source/documentation od the cdimage package. See e.g. http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/README
[12:03] <cjwatson> initrd.lz is compressed with lzma, not gzip.  use unlzma -S .lz
[12:03] <cjwatson> (might be worth making it be xz at some point so that we don't have to argue with iso9660 file formats about >3-char extensions)
[12:04] <melodie> "cpio -i < initrd
[12:04] <melodie> 185979 blocs
[12:04] <melodie> "
[12:04] <melodie> cjwatson oh so!
[12:05] <FourDollars> melodie: https://wiki.ubuntu.com/CustomizeLiveInitrd
[12:06] <melodie> cjwatson I didn't know about the "unlzma -S .lz" and renaming it to gz then gunzip then cpio worked. there is some trick under.. ?
[12:06] <melodie> FourDollars I look
[12:08] <melodie> FourDollars cjwatson TJ- sladen I appreciate your help and insights greatly! This is all very good knowledge for me. I need a cup of coffee and a piece of bread and will be right back. :)
[12:24] <melodie> cjwatson unlzma -S does that:
[12:24] <melodie> "# unlzma -S initrd.lz
[12:24] <melodie> unlzma: compressed data not read from a terminal. Use -f to force decompression.
[12:24] <melodie> unlzma: For help, type: unlzma -h"
[12:25] <melodie> I'll retry with -f
[12:25] <cjwatson> melodie: you didn't accurately transcribe what I said
[12:25] <cjwatson> -S is an option that takes an extension
[12:25] <cjwatson> unlzma -S .lz initrd.lz
[12:25] <melodie> ah!
[12:25] <melodie> ok
[12:26] <melodie> cjwatson well:
[12:26] <melodie> # unlzma -S .lz initrd.lz
[12:26] <melodie> unlzma: Decoder error
[12:26] <melodie> and:
[12:26] <melodie> # file initrd.lz
[12:26] <melodie> initrd.lz: gzip compressed data, from Unix, last modified: Thu Oct 22 22:47:26 2015
[12:26] <melodie> when I do move to gz, then gunzip, then cpio -i it works
[12:27] <cjwatson> oh, well, if your image is broken such that it's generating gzipped files and putting them in .lz ...
[12:27] <cjwatson> afaik the standard Ubuntu images are not broken in that way
[12:27] <cjwatson> $ sudo mount -oro vivid-desktop-amd64.iso /mnt
[12:27] <cjwatson> $ file /mnt/casper/initrd.lz
[12:27] <cjwatson> /mnt/casper/initrd.lz: LZMA compressed data, streamed
[12:33] <melodie> cjwatson that's intriguing I'll do a search to try to find why
[12:59] <melodie> cjwatson I'll try to see if I find a difference in the /etc/mksquashfs directory scripts
[13:03] <mitya57> slangasek, can you please subscribe the foundations team to setuptools-scm bugs (for bug 1510532)?
[13:38] <doko> mitya57, tumbleweed, barry: python3.5 now the default in xenial
[13:39] <barry> doko: +1
[13:39] <mitya57> \o/
[13:40] <rbasak> Xenial is open for general uploads now, right? That's what "Archive: open" means?
[13:41] <barry> doko: https://docs.google.com/spreadsheets/d/1PnPLZRM2hu7ucv1yuq7Fd5hjNw_DYupHIYZpoP4-xHk/edit#gid=0
[13:42] <rbasak> Only there hasn't been an ubuntu-devel-announce mail, hence I'm not sure.
[13:42] <doko> ohh, have to finish that one ... doing now
[13:43] <doko> rbasak, sure, but keep stuff migratiing, look at update_excuses
[13:43] <mitya57> doko, and thanks for quick processing of my mir/rm bugs!
[13:47] <mitya57> Why is pdf2djvu build failing on ppc64el without any log? https://launchpad.net/ubuntu/+source/pdf2djvu/0.9.2-2ubuntu1/+build/8196903
[13:47] <mitya57> Tried retrying, without any change. Built on other 5 archs successfully.
[13:50] <barry> anybody looking at software-properties i386 failure?  if not i will
[13:52] <cjwatson> mitya57: that would mean it crashed the builder
[13:53] <cjwatson> though that's an awfully quick BUILDERFAIL ...
[13:54] <cjwatson> oh, there was a DNS event earlier today, wonder if it was that
[13:57] <cjwatson> mitya57: right, it's building now, I bet it was the internal DNS outage on that nameserver that was fixed earlier.  I'll clean up the other similar occurrences
[13:57] <cjwatson> though I'm still seeing even quite recent failures
[14:05] <rbasak> doko: thanks
[14:12] <cjwatson> mitya57: definitely still something up, I've raised it with ops
[14:19] <tumbleweed> doko: \o/
[14:19] <tumbleweed> I guess my python-cffi autopkgtest fix worked then :)
[14:20] <doko> tumbleweed, we overrode it
[14:20] <tumbleweed> aww
[14:20]  * tumbleweed goes to see if it worked
[14:21] <tumbleweed> yep
[14:21] <tumbleweed> excellent
[14:21] <doko> tumbleweed, mitya57: so the one big exception is ipython (just disabled the tests). not sure if an update to the 3.x or 4.x series would be any better, but the strange thing is they do not mention python 3.5 at all on their site
[14:25] <doko> barry, fyi, I'm waiting with the 3.4 removal until -proposed is a bit more settled
[14:25] <cjwatson> ^- I'm not sure that's what I needed to see in a professional channel
[14:26] <barry> doko: +1
[14:45] <barry> bdmurray: mind doing a quick review of https://code.launchpad.net/~barry/software-properties/lp1510558/+merge/275854
[15:25] <deepak_bhagchand> i have to perform a benchmarking exercise in which i have to compare performace of two virtual machines hosting a mail server in one i have to use a full fledge operating system(linux) and in other i have to use a shell down version of the same linux in which i have to remove the modules with functionalities idont require for my application
[15:32] <rbasak> doko: I would get augeas migrating but it's stuck on a ppc64el build failure with no build log. Known issue I hear?
[15:33] <doko> rbasak, retried
[15:33] <rbasak> I tried retrying already (I think), still failed.
[15:38] <doko> rbasak, it's how you need to push the retry button ;p built.
[15:38] <rbasak> doko: thanks :)
[15:39] <rbasak> doko: FYI, the first time I got what looked like a random segfault (I did have a build log). Then on retry I failed to get build logs. In case that matters with other failures.
[15:39] <rbasak> Technically not a segfault
[15:39] <rbasak> PASS: test-wctype-h
[15:39] <rbasak> SKIP: test-wcrtomb-w32-5.sh
[15:39] <rbasak> PASS: test-verify.sh
[15:39] <rbasak> ../../build/ac-aux/test-driver: line 95: 21284 Aborted                 (core dumped) "$@" > $log_file 2>&1
[15:39] <rbasak> FAIL: test-lock
[15:48] <mitya57> cjwatson, it's fixed now, thanks for the investigation
[15:52] <cjwatson> mitya57: well
[15:52] <cjwatson> mitya57: sort of, depending on luck
[15:53] <cjwatson> rbasak: DNS resolution issue in the bos01 region, IS has been trying to figure it out this afternoon
[15:53] <cjwatson> rbasak,doko: I'll be retrying all the affected builds in bulk once it's sorted out
[15:55] <rbasak> OK, thanks.
[15:55] <slangasek> mitya57: setuptools-scm> done, though the intended process is to get agreement from the team that they will be the bug contact, and get them subscribed, before the package is promoted... (doko)
[15:55] <doko> mitya57, I agreed =)
[15:56] <doko> slangasek, I agreed =)
[15:56] <slangasek> doko: ah, and apparently did the subscription too, so ok ;)
[15:56] <doko> yes
[15:57] <doko> directhex, do you plan a mono update for this cycle?
[15:58] <directhex> doko: yes. have been snarled up by unrelated work stuff, but should have time to get that done in early december with any luck
[15:58] <doko> ta
[15:58] <directhex> 4.0 or 4.2 series, depending on QA
[15:59] <directhex> the packaging work is ~done since i get paid to do it, it's the distro integration which takes time now
[17:06] <stgraber> infinity: TB meeting?
[17:27] <TJ-> any network-manager maintainer about? I'm trying to debug bug #1048430 and it seems to depend on an Ubuntu-specific patch adding DBus dnsmasq updates
[17:28] <cjwatson> rbasak,doko,mitya57: all fixed now for real thanks to IS figuring out that one of the two DNS forwarders was busted
[17:31] <rbasak> Thanks
[17:37] <cjwatson> http://blog.launchpad.net/ppa/ppas-for-ppc64el may be interesting to people who want to work on ppc64el build failures
[18:24] <ogra_> cjwatson, erm, did someone just switch the image builders to default to xenial ?
[18:24]  * ogra_ just had a (what he thought) wily rebuild explode on all arches
[18:25] <infinity> ogra_: xenial's the devel series, not sure what you expect.
[18:25] <infinity> ogra_: A wily build would need DIST=wily
[18:26] <ogra_> infinity, dunno, that image builds only default to it once it actualy can build ... i.e. once the archive is complete enough :)
[18:27] <infinity> The arvhive is "complete" from day 1...
[18:27] <infinity> archive, too.
[18:27] <infinity> It's not like we start from scratch.
[18:27] <ogra_> well, i have different 404s on the different arches in the logs
[18:27] <infinity> Log?
[18:28] <ogra_> oh and we use a PPA
[18:28] <ogra_> which also doesnt have xenial support yet
[18:28] <infinity> Right, if your PPA is 404ing, you could mass copy from wily to xenial. :P
[18:29] <ogra_> well, i could just turn on xenial at all for the PPA, prehaps thats sufficient ...
[18:32] <cjwatson> ogra_: yeah this is just your PPA
[18:32] <ogra_> right
[18:32] <cjwatson> ogra_: you can only "turn it on" by uploading or copying something into it
[18:32] <ogra_> i just did a xenial upload to it, that should get me the Packages files
[18:33] <cjwatson> mass copying would normally be sensible, why not do that?
[18:33] <ogra_> the wily stuff should all be in archive already anyway
[18:33] <cjwatson> ok, well, either make the Packages files exist, or make your lb config stop using the PPA, one or the other
[18:34]  * ogra_ would like to only use the PPA for overrides and in case something is missing, directly copy to the archive 
[18:34] <ogra_> a new release is a good reason to clean up :)
[18:45] <dobey>  or make it not fail if the Packages file in the PPA doesn't exist :)
[18:45] <dobey> robustness ftw
[18:46] <ogra_> i guess that would have to be hacked into apt
[19:04] <infinity> dobey: I wouldn't call that robust, I'd call it just the opposite.  If you ask it to use a PPA and the PPA is busted, that *should* fail.
[19:05] <infinity> So, the only correct answers are "don't use the PPA" or "populate the PPA".
[19:15] <dobey> potato, legume
[19:48] <teward> with a Conflicts: line in a package, is there such a thing as version not equal to the version provided in the source package?
[19:48] <teward> (i.e. this:    Conflicts: package (!= ${source:Version}),...
[20:07] <gQuigs> is anyone already planning a systemd related UDS session?  (I'd like to discuss systemd user sessions, but it doesn't seem to warrant a session to itself)
[21:03] <sil2100> cyphermox, doko: re: the ocaml transition, looking at xstrp4 it seems that the installability issue would be resolved by us pullin in the camlp4 source package from Debian - which, on the other hand, requires us to first merge the new ocaml version from Debian
[21:04] <sil2100> cyphermox, doko: so I guess this would have to wait as doko mentioned Debian prepares a new ocaml version anyway or something
[21:05] <sil2100> Moving forward
[21:13] <sil2100> cyphermox, doko: anyway, how would you guys prefer me to resolve those issues? Since for most cases I don't have the permissions to merge/sync - is poking here ok?