[02:27] <lamont> is it bad that I did a dist-upgrade on wily and time stopped on my topbar?
[02:27]  * lamont reboots for giggles
[06:58] <pitti> juliank, cyphermox: seb128 pointed  out the upower bug to me yesterday, but I wasn't aware of that reproducer, thanks!
[07:01] <pitti> cyphermox: I suppose bug 1547518 is just a duplicate of that
[08:22] <dholbach> good morning
[08:37] <doko> pitti, python3.5's libreoffice hint needs a version update
[08:42] <pitti> done
[08:59] <Mirv> is there someone to whom cookies, TLDs and rfc6265 ring a bell? something changed between Wed and Fri last week causing bug #1548686, and I'm wondering if it's Ubuntu or something on the Internet (but builders shouldn't have access to the network anyway so I guess nothing should normally change)
[09:04] <LocutusOfBorg> slangasek, probably :D
[09:10] <Mirv> well I'm testing a wily build now. if it succeeds, something changed in xenial. if it fails too, something changed in the world.
[09:39] <doko> sil2100, the last ubuntu-keyboard upload still depends on fonts-droid
[09:39] <sil2100> eh, let me get the dev
[10:48] <ginggs> pitti, xnox: what is the reason for keeping pybootchartgui around until *after* the LTS? LP: #1353587 It is one of the three packages remaining in Ubuntu that directly depend on python-support
[10:49] <pitti> ginggs: I thought xnox wanted to keep it for measuring ubuntu-touch
[10:49] <pitti> I don't mind removing it, we can always get it from wily or a PPA, though
[10:49] <pitti> on touch you can't directly apt-get install it anyway
[10:51] <ginggs> pitti: sounds good, what else needs to be done to get rid of python-support? LP: #1535318
[10:52] <ginggs> shall I add the rdepends as affected packages?  they are listed in the bug description
[10:54] <pitti> yeah, makes them easier to find
[11:03] <ginggs> pitti: launchpad had a few timeouts, but i've now added firmware-addon-dell and qdigidoc (but not the reverse-recommends bootchart and phablet-tools)
[11:07] <Mirv> ok qtbase succeeded on wily so the bug is on xenial
[12:05] <Odd_Bloke> rbasak: How is work on the git importer going?
[12:07] <rbasak> Odd_Bloke: check with nacc please
[12:07] <rbasak> Odd_Bloke: BTW, I have some tooling to import things manually, apart from one tweak to the format of the commit that cjwatson convinced me to make.
[12:07] <rbasak> (if that's helpful to you)
[12:16] <Odd_Bloke> rbasak: Ack, will do; I didn't see him online yesterday so didn't know if he was on VAC or somesuch. :)
[12:16] <Odd_Bloke> rbasak: We're happy to wait; just don't want to wait unnecessarily. :p
[12:32] <Saviq> pitti, hey, shouldn't the qtmir/qtmir-gles builds against proposed mir be proposed qtmir, too? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
[12:45] <pitti> Saviq: normally not, as they are separate packages
[12:46] <pitti> Saviq: you can either force that by versioned Depends:/Breaks: (if the new mir breaks qtmir, that's cleaner), or if this is a test-only issue I can also re-run them against all of -proposed
[12:47] <Saviq> pitti, I thought this was taken care of (like you guys marked mir and qtmir to always run together from -proposed)
[12:48] <pitti> Saviq: no, there's no way to mark that
[12:48] <pitti> Saviq: the way to say "foo/2 can only work with bar >= 3" is "Depends: bar (>= 3)" :)
[12:49] <Saviq> pitti, well, yeah, it'd have to be Breaks: in this case, since it's the old qtmir that fails with new mir
[12:49] <Saviq> and that's expected
[12:50] <Saviq> pitti, can you tell why the armhf version tested was the -proposed one, actually?
[12:50] <pitti> Saviq: it hasn't been tested yet
[12:50] <pitti> autopkgtest for qtmir 0.4.7+16.04.20160219-0ubuntu1: armhf: Test in progress
[12:50] <pitti> that version is meaningless
[12:50] <Saviq> ack
[12:50] <pitti> and I have a work item to not show it
[12:51] <pitti> Saviq: so, want me to re-run against all of -proposed?
[12:51] <doko> pitti, please hint diffoscape for python-setuptools
[12:51] <Saviq> pitti, well, can you please restart them with all of -proposed and I'll file a bug against mir to add Breaks: as part of a release
[12:52] <pitti> Saviq: queued
[12:52]  * Saviq always felt weird about Breaks:, not that I have a better solution...
[12:52] <pitti> doko: it already had a hint, bumped the version
[12:53] <pitti> that'd be another useful case of hinting diffoscope/ppc64el instead of a version
[12:53] <pitti> Saviq: well, it's weird in either case -- that means that Mir broke its ABI without bumping the soname?
[12:55] <Saviq> pitti, well, actually... the real problem is likely the dummy test qtmir has - it really just tries to rebuild the package, which fails against new Mir
[12:55] <Saviq> /likely/
[12:55] <Saviq> pitti, I meant to drop that test since it ~doesn't make sense in autopkgtest
[12:56] <Saviq> it was my try to find out when a package in proposed would break a downstream build
[12:58] <xnox> ginggs, pitti: indeed, touch uses upstart. i don't mind, we can drop it. Or like port it to dh_python[23] which should not be that hard.
[12:58] <Saviq> pitti, a Breaks: doesn't make sense here, either, exactly why you said - sonames are bumped as needed, so that will enforce dependencies to be correct
[13:16] <pitti> doko: FYI, before you waste time on the libgps21 NBS: I filed bug 1548811, will track that down
[13:21] <doko> pitti, I think I filed one too ... can't find it
[13:21] <doko> pitti: what was the outcome for gsoap, override the virtualbox test failure?
[13:24] <ginggs> xnox: how was firmware-addon-dell 'fix released'?
[13:26] <xnox> ginggs, it doesn't build-depend nor use python-support.
[13:27] <xnox> ginggs, Convert to dh_python2. -> since 2013. So no actions are needed for it.
[13:27] <ginggs> xnox: true, i only added it today because it is a reverse-depends of firmware-tools (see comment #34 in that bug)
[13:27] <xnox> ginggs, yeah, that one still needs fixing, which i'm doing.
[13:27] <xnox> ginggs, it doesn't make sense to add reverse-depends like that.
[13:28] <ginggs> xnox: noted.  the only other reverse-depends i added there was qdigidoc
[14:05] <pitti> doko: ah, can do
[14:21] <xnox> ginggs, once my uploads migrate, i believe we will be good to remove python-support.
[14:22] <ginggs> xnox:  \o/
[14:23] <ginggs> xnox: i see you uploaded rather than removing, what do you think of fixing firmware-extract which was removed?
[14:23] <ginggs> i believe it's a plugin for firmware-tools
[14:24] <xnox> ¯\_(ツ)_/¯ -> really not my problem =) and i have no clue what these tools are, and wether they work at all anymore.
[14:24] <doko> pitti, ta, python-setuptools now waits for britney to learn about the fixed python-pex
[14:26] <xnox> ginggs, i think all of that is replaced with uefi capsules updates these days, rather than firmware-tools stuff.
[14:26] <xnox> superm1, are firware-tools still in use/required to do things?
[14:27] <superm1> xnox: not on workstation or client
[14:27] <superm1> Possibly on server
[14:27] <xnox> superm1, well it gained brand new support for dh-python2 instead of python-support, so it will live another lts untouched, hopefully =)
[14:38] <sil2100> LocutusOfBorg: hey! Is there an LP bug for getting rid of fonts-droid ?
[14:41] <seb128> sil2100, see "Fonts-droid has been deprecated and removed, please update your dependency :)" on ubuntu-devel@
[14:41] <seb128> you replied to that discussion you should know about it?
[14:42] <seb128> there is a bug mentioned in the discussion as well
[14:45] <seb128> shrug, did optipng become slower on xenial? I remember it taking a while but now it takes ages it feels like
[14:51] <LocutusOfBorg> sil2100, nope, I didn't open any bug :)
[14:58] <sil2100> seb128: yeah, I know, I didn't remember seeing a bug on the initial e-mail
[14:58] <sil2100> But there was one later on I see now
[15:03] <smoser> hey. we're seeing server iso test failures
[15:03] <smoser> https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/59/
[15:04] <smoser> what seems key there to me is the syslog: https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/59/artifact/log/utah-10459.syslog.log
[15:04] <smoser> which shows failure to install packages because of
[15:04] <smoser> The following packages have unmet dependencies:
[15:04] <smoser>  libpam-systemd : Depends: systemd (= 229-1ubuntu2) but 229-1ubuntu4 is to be installed
[15:04] <smoser>  lxc : Depends: iptables but it is not going to be installed
[15:04] <smoser> Unable to correct problems, you have held broken packages.
[15:05] <smoser> the word 'held' seems probably important there. the install seems to have access to the archive, but I dont know why 'iptables' would not be available.
[15:19] <Kryczek> smoser: may I ask what tool chain do you use to build server ISOs? I tried to look at the log but I am guessing it is firewalled :)
[15:20] <smoser> Kryczek, fudge. i can pastebin the log for you.
[15:20] <smoser> i'm pretty sure its 'debian-cd'
[15:20] <smoser> but i've never actually touched any of that.
[15:21] <smoser> i'd have to ask cyphermox  or infinity for that info.
[15:21] <smoser> Kryczek, http://paste.ubuntu.com/15180824/
[15:22] <cyphermox> yes, CDs are built by debian-cd, among other things
[15:22] <cyphermox> that's not a cd build issue though
[15:23] <cyphermox> it happens regularly that systemd isn't done transitioning, that's usually fixed by the next build
[15:23] <Kryczek> ah ok, not the Debian Live (live-build) tool chain then? Just wanted to point out that it is unmaintained unfortunately
[15:23] <cyphermox> oh, missing iptables too
[15:24] <utlemming> pitti: er, seeing something really odd. If you define 'console=ttyS1' for the kernel CLI, then systemd just hangs
[15:24] <Kryczek> smoser: thank you for the paste
[15:24] <utlemming> pitti: the change happened about a week ago
[15:24] <cyphermox> Kryczek: some builds do use live-build, I'm not sure which precisely.
[15:25] <doko> pitti, barry, virtualenv still triggers test failure for tox
[15:25] <Kryczek> cyphermox: would be funny if it was "precise" ;D
[15:25] <smoser> cloud-image builds use live-build
[15:25] <cyphermox> there we go ;)
[15:25] <smoser> cyphermox, 'isnt done transitioning'
[15:25] <smoser> ?
[15:26] <smoser> as in only parts of systemd got into xenial/ from xenial-proposed  ?
[15:27] <barry> doko, pitti yeah, that makes no sense and i can't reproduce it locally :(  any thoughts on how to debug the problem?
[15:27] <pitti> manjo: what's the status on bug 1548120? it's "block-proposed", and thus blocks further uploads of i-t
[15:28] <cyphermox> smoser: the systemd failing to install in that paste means, IIRC, that systemd wasn't all done moving from proposed to releae at the time the CD was built, yeah. I may be oversimplifying this, but it's an issue that happens with the dailies and you don't have to do anything special.
[15:29] <pitti> barry: socket.timeout: timed out
[15:29] <pitti> barry: is that trying to call out to the interwebs without using the $*_proxy vars perhaps?
[15:31] <manjo> pitti, I need to test apw's version of the patch
[15:31] <barry> pitti: do you see that timeout in the tox test?  i don't
[15:32] <pitti> requests.packages.urllib3.exceptions.ConnectTimeoutError: (<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7faf4e29dd68>, 'Connection to pypi.python.org timed out. (connect timeout=15)')
[15:32] <pitti> barry: this looks pretty clear?
[15:32] <pitti> I mean that it tries to get stuff from the network, apparently not using the proxy?
[15:32] <barry> pitti: yes, but which log is that in?
[15:32] <apw> pitti, i made it block-proposed deliberatly because what is in the current -proposed isn't something i want out
[15:32] <pitti> barry: the one linked from excuses, e. g<EMAIL_ADDRESS>[15:33] <pitti> apw: ok; my upload isn't urgent at all, so ok for now
[15:33] <apw> pitti, if you want to send me over the diff i can merge it with the "next" one
[15:33] <apw> with the fixed fix for this mess
[15:34] <barry> pitti: i'm looking at 20160223_blah
[15:35] <barry><EMAIL_ADDRESS>[15:35] <barry> it ends in pkg_resources.extern import error
[15:35] <pitti> ah, that's a different one indeed
[15:36] <barry> pitti: you'd expect that to be locally reproducible with, e.g.: `adt-run tox -- schroot xenial-amd64` yeah?
[15:36] <pitti> --apt-pocket=proposed -U tox
[15:36] <barry> (assuming of course -proposed is enabled in that chroot)
[15:36] <pitti> but I just run that (with qemu), and it works
[15:37] <barry> pitti: yeah, that's weird right? :)
[15:37] <smoser> cyphermox, hm.. well, it'd seem a general issue if we're moving parts of a source package at a time from -proposed.
[15:37] <smoser> i'd have thought that would be all at once for a source package.
[15:37] <cjwatson> it's not possible to move parts of a source package at once, so no, that doesn't happen
[15:38] <barry> pitti: the error happens when trying to install pytest>=2.3.5, pytest-timeout.  we have pytest 2.8.7.  yeah it passes for me too
[15:40] <smoser> cjwatson, not possible ?
[15:41] <smoser> as in only one binary package can be moved at a time?  or just as in not implemented.
[15:42] <cjwatson> what
[15:42] <cjwatson> no, the opposiute
[15:42] <cjwatson> the primitive operation here is "copy source package (with binaries)"
[15:42] <smoser> right.
[15:42] <smoser> thats what i would have thought.
[15:42] <smoser> so then it must be the 'held' part of the message that causes the failure ?
[15:43] <smoser> "Unable to correct problems, you have held broken packages."
[15:43] <cjwatson> not relaly
[15:43] <cjwatson> the message you quoted does not contain enough information to work it out
[15:43] <smoser> woudl you take a look at the link or the paste ?
[15:43] <cjwatson> "is not going to be installed" is apt-speak for "this package is available, but when I try to install it I get broken dependencies, and I'm not going to tell you why"
[15:44] <cjwatson> apt typically doesn't print enough information to diagnose this class of problem just from its output
[15:44] <cjwatson> you have to set up a matching environment (in chdist or whatever) and test-install things with increasing constraints until it gives you useful answers
[15:44] <cjwatson> however, in this case it could be that the squashfs base system is out of date
[15:45] <smoser> i'd guess you're right that the squashfs is out of date.
[15:45] <smoser> but then why wouldn't it pull whatever it needs from the archive.
[15:46] <cjwatson> well, we could spend hours investigating that, or I could go fix the stuck builds that are causing the OOD squashfs
[15:46] <cjwatson> the latter being the correct solution anyway :)
[15:46] <pitti> barry: I just ran it in production (manually), and get the socket timeouts again
[15:46] <sil2100> LocutusOfBorg: hey! Could you answer some questions regarding the fonts-droid deprecation to Elleo?
[15:46] <sil2100> LocutusOfBorg: Elleo is the person responsible for ubuntu-keyboard
[15:46] <cjwatson> the key bit of log output here is noting the presence of "Parallel build" near the top of http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20160223.log
[15:47] <sil2100> And it seems the switch of that is not as obvious
[15:47] <smoser> so what is to be done to fix stuck builds ? im' fine with that other than it just means this happens at some other point.
[15:47] <Elleo> LocutusOfBorg: heya, just removing fonts-droid we lose some characters we need for chinese, but it seems impractical to replace it with fonts-noto-cjk as that's nearly 100MB larger than fonts-droid (and space is a concern issue on touch images)
[15:47] <cjwatson> when more than one build is happening at once on cdimage, then we don't sync the archive because doing that in the middle of another build is bad news
[15:48] <cjwatson> this is normally allowable, but if it gets confused for some reason then we can end up *never* syncing cdimage's mirror
[15:48] <Elleo> LocutusOfBorg: unless you know of any other smaller font package that could do the job?
[15:48] <cjwatson> and that's bad, and eventually people notice due to this kind of thing
[15:48] <cjwatson> now, I fixed most of the common causes for this a while back
[15:48] <cjwatson> but I suspect that the reboot of nusakan the other day happened at a suboptimal time, and left some confusion around
[15:49] <cjwatson> because the semaphore of "how many builds are running" has a value two higher than it ought to be
[15:50] <LocutusOfBorg> Elleo, fonts-droid-fallback?
[15:50] <cjwatson> so I've manually decremented it twice ("semaphore decrement-test /srv/cdimage.ubuntu.com/etc/.sem-build-image-set" as cdimage@nusakan) and that should clear things once the build that's currently in flight finishes
[15:50] <barry> pitti: can you figure out what it's trying to download from pypi?  odd too that the timeout is completely different from the autopkgtest log traceback
[15:50] <LocutusOfBorg> or fonts-noto?
[15:50] <LocutusOfBorg> I don't know about the chinese issue, and I'm not understand why debian is not aware of it
[15:50] <Elleo> LocutusOfBorg: fonts-noto doesn't include chinese characters
[15:50] <barry> pitti: and *that's* strange because the traceback doesn't at all match the code i get locally when i create the tox environment form the `built` test
[15:51] <Elleo> LocutusOfBorg: will give fonts-droid-fallback a go and see if that has what we need
[15:51] <cjwatson> logs suggest that this situation started on the 20th, which would match up with nusakan's reboot on the 19th
[15:51] <pitti> barry: it's not, it's exactly the same log as<EMAIL_ADDRESS>[15:51] <pitti> barry: as for that other error, I don't know what that means, maybe transient?
[15:52] <LocutusOfBorg> thanks Elleo
[15:52] <Elleo> LocutusOfBorg: I don't see a fonts-droid-fallback package anywhere?
[15:52] <barry> pitti: okay, but in that log file you just pasted, search for "socket".  the only 2 occurrences have nothing to do with socket.timeout
[15:52] <smoser> cjwatson, thank you. we'll hope it works itself out.
[15:52] <smoser> nuclearbob, ^ matsubara ^
[15:53] <cjwatson> I think maybe ideally we'd have a sort of multi-pid-file rather than a counting semaphore there
[15:53] <cjwatson> then it would be possible to automatically recover from this sort of situation
[15:53] <cjwatson> but fortunately it's not all that common after the fix I applied in December
[15:53] <cjwatson> (cdimage r1557)
[15:53] <pitti> barry: sorry, that was the link you posted; I meant<EMAIL_ADDRESS>[15:53] <matsubara> thanks cjwatson for kicking things again
[15:53] <LocutusOfBorg> Elleo, https://launchpad.net/ubuntu/+source/fonts-android
[15:53] <matsubara> and you too smoser
[15:54] <LocutusOfBorg> fonts-droid-fallback_6.0.1r16-1_all.deb (1.7 MiB)
[15:54] <barry> pitti: ah 20160222
[15:55] <Elleo> LocutusOfBorg: ah, thanks
[15:55] <nuclearbob> smoser: fwiw, the problem seemed to be that the already installed version of systemd (presumably in the squashfs) was higher than the version of libpam-systemd in /pool on the cd
[15:55] <barry> pitti: so, if we ignore 20160223 and look at 20160222, then maybe i can make more progress, but it bothers me that we have two different failures, neither of which is reproducible locally ;)
[15:57] <cjwatson> nuclearbob: ah yes, that's why it doesn't just pull whatever it needs from the archive, because in this case that archive is on the ISO and the result would be a downgrade
[15:57] <barry> pitti: is there a way for you to run tests on production without an upload?
[15:57] <pitti> barry: yes (that's what I just did)
[15:57] <cjwatson> and apt doesn't do downgrades by default
[15:57] <smoser> but how would the archive have older ?
[15:57] <pitti> barry: I can also run it, use --shell, and then give you ssh to it
[15:57] <smoser> the cd was built from the archive
[15:57] <cjwatson> smoser: not quite
[15:57] <cjwatson> smoser: it was built from an rsynced mirror of the archive
[15:57] <cjwatson> smoser: which, due to the situation explained above, hadn't actually been rsynced for several days
[15:58] <cjwatson> smoser: but the squashfs is built on LP directly from the archive
[15:58] <barry> pitti: that could help.  what i'm thinking is that i could make an educated guess as to the failure, make a change and hand you a source package to see if production passes or not
[15:58] <smoser> ah.
[15:58] <smoser> ok. that makes sense then.
[15:58] <cjwatson> so if cdimage's mirror gets stuck this way then it's possible for it to be older
[15:58] <barry> pitti: but ssh would definitely let me poke around some more
[15:58] <barry> (i.e. put the "educated" in "educated guess" :)
[15:59] <cjwatson> in normal circumstances it isn't possible for it to be older, because we deliberately try to sync the archive after doing the squashfs build
[15:59] <cjwatson> for exactly this kind of reason
[15:59] <pitti> barry: ok, it'll take some minutes until the test finished
[16:04] <Elleo> LocutusOfBorg: fonts-droid-fallback seems to work thanks, still need to test it a bit more to be absolutely certain but it looks promising
[16:07] <LocutusOfBorg> wonderful!
[16:07] <LocutusOfBorg> thanks a lot for the feedback/fix
[16:15] <pitti> apw: the transitional linux-meta packages on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- these should be seeded, I suppose?
[16:19] <apw> pitti, a good point, do we have to seed them alllll explicity or is there something else we should be doing in the kerenl package
[16:19] <pitti> apw: they are just for upgrades from previous releases, they'll all go after xenial, right?
[16:20] <apw> pitti, that indeed
[16:20] <pitti> apw: so they won't be a dependency of anything, hence they need seeding, yes
[16:20] <pitti> apw: if *all* binaries from linux-meta should be in main, then seeds have a syntax for that
[16:22] <apw> pitti, i don't believe we have any primary packages (.deb) which are not for main in any of our packages
[16:23] <apw> pitti, but that they are listed explicity is worrysome
[16:23] <pitti> apw: in supported-kernel-common? yeah
[16:23] <pitti> apw: and a lot of them are obsolete too
[16:24] <pitti> supported-kernel-common: * linux-signed-generic-lts-quantal
[16:24] <apw> pitti, i would normally look at infinity at this point, as he would have gotten us as far as here
[16:24] <pitti> apw: I figure it'd be a lot simpler to just replace all of that with "all sources of linux-meta" (whatever the syntax was)
[16:24] <pitti>  * (srcpkgname)
[16:24] <pitti> perhaps?
[16:25] <apw> pitti, i can't see a reason that would be wrong these days, we did use to have split flavours once-upon-a-time
[16:25] <pitti> ah no, those were recommends
[16:25] <pitti> apw: aah, man germinate
[16:26] <pitti>  * %linux-meta
[16:26] <pitti> apw: ^ this should do it
[16:29] <apw> pitti, cool thanks for fixing our messes :)
[16:30] <pitti> apw: oh, I wasn't actually changing the seeds, but I can if you confirm that's the right thing
[16:30] <pitti> that == all binaries of linux-meta
[16:30] <apw> pitti, i'll take it and figure that out definatlvly and get back to you
[16:31] <apw> (or to me, depending)
[16:32] <pitti> apw: I figure we could start with replacing the entire supported-kernel-common with just %linux-meta, and then see what falls out of that?
[16:32] <pitti> i. e. wait for a publisher cycle and check component-mismatches
[16:32] <apw> pitti, if its not going to cause chaos, that sounds like a plan
[16:32] <pitti> apw: well, I figure kexec-tools and thermald should stay, but all others
[16:33] <pitti> apw: no, not at all; supported-* isn't defining images, just stuff that's in main despite *not* being on any image
[16:33] <pitti> apw: we might have soem linux-meta-$flavor which should stay in universe, all others should be there in the seed
[16:34] <apw> pitti, we have other linux-meta-foo sources which produce things whihc should be, but not from linux-meta i don't think any more
[16:34] <apw> 'should be in universe"
[16:37] <cjwatson> snakefruit (proposed-migration, people.canonical.com/~ubuntu-archive/, etc.) will be going down for reboot for a little while shortly; I've shut down archive cron jobs there in preparation
[16:53] <cjwatson> snakefruit back
[16:53] <cyphermox> pitti: could you point me to your bug about setting up multiple crypted drives in the installer you mentioned yesterday? I can't find it anymore
[16:54] <pitti> cyphermox: bug 1548252 ?
[17:03] <nacc> slangasek: now that FF is in effect, how do syncs with Debian work? e.g., for php7.0 to pass its autopkgtests, we need (at least) php7.0.3-6 (7.0.3-7 is in unstable as well). Do I need to file a bug to request the sync (technically it's mentioned in LP: #1547738)
[17:04] <nacc> slangasek: actually, i guess they are merges now, since we have a delta ... I can do that merge (and I think we can drop some of the delta now that xmlrpc-epi is in main). So would i put the resulting debdiff in that bug then? and mark it as a FFe?
[17:05] <cyphermox> pitti: thanks
[17:14] <jdstrand> tyhicks: fyi, not sure if you noticed but your apparmor upload got stuck
[17:15] <jdstrand> tyhicks: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says 'autopkgtest for systemd 229-1ubuntu4: ppc64el: Test in progress'
[17:15] <jdstrand> tyhicks: iirc, it has said that for days
[17:18] <pitti> ah, that's not tyhicks's bug
[17:18] <pitti> sorry, I'll unstick it
[17:19] <tyhicks> thanks pitti!
[17:21] <pitti> i. e. I re-run the test, the reason for the temporary failure got fixed
[17:21] <jdstrand> cool
[17:21] <jdstrand> thanks pitti :)
[17:22] <jamespage> pitti, thanks for working the tomcat8 transition through btw
[17:23] <doko> nacc, slangasek: it's not yet available for syncing, doing it later
[17:25] <nacc> doko: 7.0.3-6 is available, i think ... but we can wait for -7, do you want a debdiff for the merge to do it?
[17:26] <cjwatson> smoser: OK, I might have accidentally slipped and rewritten cdimage's locking code so that it tracks multiple pids rather than just a count and automatically removes dead processes from its tracking.  Not committing it quite yet because there are builds in progress, but I'll deploy it once everything's quiet.
[17:26] <cjwatson> http://paste.ubuntu.com/15181704/
[17:29] <doko> nacc, no, will sync it when I'm back home tonight
[17:29] <nacc> doko: ok, thanks!
[17:38] <xnox> pitti, doko, cjwatson: please RM python-support
[17:38] <xnox> https://bugs.launchpad.net/ubuntu/+source/python-support/+bug/1535318
[17:38] <pitti> w00t!
[17:38] <xnox> all clear.
[17:39] <doko> me, me ...
[17:39] <pitti> doko: do you want to ... have the honor?
[17:39] <pitti> yeah, I'll leave it to doko, he really deserves it more
[17:40] <pitti> . o { https://launchpad.net/~ubuntu-cruft-busters ! }
[17:46] <doko> Comment: fiiiiinally, lp: #1535318, remove python-support
[17:46] <doko> 1 package successfully removed.
[17:51] <xnox> doko, i see that landscape client is python2 and twisted, do we have working python-twisted-conch|-core|-web in python3 yet?
[17:52] <xnox> i see that those bits are in python3-twisted.
[17:55] <doko> xnox, yes, everything which is in the package should be supported
[18:00] <Pharaoh_Atem> nacc: did you see my message on LP #1547738?
[18:05] <seb128> bdmurray, hey, do you have any opinion on https://code.launchpad.net/~seb128/software-properties/newtab-enable-proposed/+merge/286626 ? I know you suggested dropping it but that let a graphical way to enable proposed and that's what willcooke suggested doing after talking to ara and mpt
[18:05] <nacc> Pharaoh_Atem: yeah
[18:05] <seb128> I've no opinion either way, I think it's better than we have now so I'm trying to land it, we can still do other changes later if something else is decided
[18:07] <bdmurray> seb128: I think I suggested dropping it if the release is still in development, but I didn't see an easy way to do that. And yes this does seem like an improvement.
[18:13] <nacc> Pharaoh_Atem: it should get sync'd tonight
[18:15] <xnox> barry, is there 2to2and3 tool yet? cause the output 2to3 generates is questionable.
[18:15] <xnox> e.g. ideally i want "from __future__ import print function" et.al.
[18:16] <barry> xnox: http://python-future.org/automatic_conversion.html
[18:17] <xnox> omg, i love this "pasteurize"
[18:17] <barry> cute, huh? :)
[18:25] <nacc> slangasek: doko: if we want to pull the xmlrpc binpkg back in, when we sync with 7.0.3-7, would you want a bug & debdiff for that?
[18:49] <Pharaoh_Atem> nacc: is that tonight in US timezone or UK timezone?
[18:50] <nacc> Pharaoh_Atem: doko's timezone :)
[18:50] <Pharaoh_Atem> so CEST+1
[18:51] <Pharaoh_Atem> which means it'll sync now?
[18:51] <Pharaoh_Atem> ;)
[18:51] <nacc> Pharaoh_Atem: it'll sync when it syncs :)
[18:56] <nacc> Pharaoh_Atem: would you have some time to look at LP: #1548442 ?
[19:07] <Pharaoh_Atem> nacc: yeah, sure
[19:08] <nacc> Pharaoh_Atem: thanks, working on package builds and stuff
[19:55] <Pharaoh_Atem> errm
[19:56] <Pharaoh_Atem> I'm getting hash sum mismatch errors for "apt update" in universe
[19:57] <sarnold> try again in a few minutes
[19:57] <nacc> Pharaoh_Atem: yeah, it happens :)
[20:44] <coreycb> arges, bdmurray, Hi, we have a ceilometer SRU in the wily queue that could use a review
[20:48] <arges> coreycb: ok
[20:51] <coreycb> arges, thanks
[20:52] <Pharaoh_Atem> nacc: welp, I'm getting two different errors on two different machines (ubuntu 16.04 + php7.0-7.0.3-3, CentOS 7.2 + php70-7.0.3-1.el7.remi)
[20:52] <Pharaoh_Atem> and the best part? neither of them are giving me the error you got
[20:56] <Pharaoh_Atem> I'm compiling php7.0-7.0.3-6 for debian 8 and giving it a go to figure out what's going on here
[21:05] <arges> coreycb: so bug 1530913 is going to be superceedd by this
[21:06] <coreycb> arges, yes, that was the prior point release
[21:07] <arges> coreycb: well it is still in proposed, does it need to be released first, or is this bug fixing something with that
[21:07] <coreycb> arges, oh..  I didn't realize that.  no as far as I know the old one was tested and is ok.
[21:08] <arges> coreycb: ok
[21:08] <coreycb> arges, thanks, let me know if it's stuck for a reason
[21:08] <arges> coreycb: ok done
[21:09] <coreycb> arges, thanks1
[21:09] <coreycb> explanation point fail
[21:09] <coreycb> I can't type
[21:49] <nacc> Pharaoh_Atem: ok, thanks, the above was seen was with 7.0.3-5
[22:11] <slangasek> nacc: FFe is only needed if the changes you're making (whether by merge from Debian or otherwise) are features.  If this is just bugfixes, no FFe is required.
[22:12] <slangasek> doko: sorry, don't know why you hightlighted me, what was not available for syncing?
[22:13] <nacc> slangasek: i think php7.0.3-7, just for your reference
[22:13] <slangasek> ok
[22:13] <slangasek> which I think is not meant to be a sync anyway
[22:13] <nacc> slangasek: ok, it could be a bit of both? as php7.0 is under active dev, but will wait to see what doko says
[22:13] <nacc> slangasek: right, it'd be a merge now, aiui?
[22:14] <slangasek> yes
[22:15] <nacc> slangasek: ok, so for pkg-php-tools, looks like one fix is upstream already (in debian's git). I am sending the other one in now
[22:16] <slangasek> excellent
[22:16] <slangasek> nacc: I'm probably not available to help with sponsorship for the next day or so fwiw
[22:16] <nacc> slangasek: not sure how to make the test make sense for them, as the error message will vary between php5 and php7, and it's a phpunit comment that provides the matching string, but they'll know what to do
[22:16] <nacc> slangasek: ok, np
[22:19] <nacc> slangasek: would it be better for me to provide a debdiff from what is currently in xenial to a level that works or request a fresh sync and provide a debdiff to that?
[22:21] <slangasek> nacc: a sync is *only* ever for a package that we want to have a package uploaded to Ubuntu that's identical to the one in Debian.  Otherwise it's a merge; for a merge you can provide a debdiff against either the existing Ubuntu package (xenial-proposed or xenial), or against the new Debian version that you're asking to have merged
[22:21] <slangasek> nacc: and merges.ubuntu.com is your friend
[22:22] <nacc> slangasek: got it, thanks
[22:25] <xnox> slangasek, i have things in NEW, do that need FFe or not?
[22:26] <slangasek> xnox: source NEW - no, it just requires securing an AA's time
[22:26] <xnox> slangasek, gotcha. hope you are having fun =) and not spending too much time on irc =)
[22:27] <slangasek> xnox: yeah, I'm about to run away ;)
[22:27] <xnox> \o/
[22:27] <Unit193> Alright, I give up.  How do I specify the filesystem that filesystem.squashfs should be mounted udf, not iso9660?
[22:29] <xnox> Unit193, filesystem.squashfs is a squashfs =)
[22:29] <Unit193> xnox: I know, but it sits on media, which has a filesystem.
[22:30] <Unit193> And I don't know how to continue boot from busybox after remounting /cdrom with -t udf.
[22:34] <Unit193> Ooh, worked to recover from busybox this time.  Though it's still trying iso9660 which is not going to work.
[22:45] <barry> doko, pitti: new tox syncpackaged.  let's see if that gets us past proposed
[22:45] <Unit193> xnox: So, no ideas?
[22:54] <stefanct> hi there. i am the upstream maintainer of flashrom. the debian maintainer has not updated his package for a while but did so now... however as you know the LTS freeze is in place and we would need an exception
[22:55] <stefanct> the now published debian package is of an upstream rc and thus will probably become outdated in a week when we do a full release
[22:56] <stefanct> id like to know what is preferable... getting an exception for the rc now and request a pull in about a week or if we should wait till the full upstream release is done and packaged for debian in about a week
[23:08] <tarpman> stefanct: freeze? debian isn't in any freeze right now AFAIK
[23:09]  * tarpman looks at what channel he's in and shuts up
[23:09] <stefanct> :)
[23:09] <stefanct> flashrom was always pulled in from debian
[23:09] <sarnold> stefanct: i'm guessing a week's delay would be fine, though it might not be a bad idea to start the paperwork early
[23:10] <stefanct> sometimes with a sponsored upload after a freeze... but we never had to build a package (someone of you always helped out so far ;)
[23:10] <stefanct> but yes, the bug report is there but we need to fill it
[23:21] <nacc> doko: fwiw, the merge with -7 isn't exactly straightforward (and the delta changes, i'm testing my debdiff now, but i can file a bug and send it your way if you want)
[23:40] <doko> nacc, ta, I'm just back, best thing would be a bug report, and subscribe me
[23:40] <nacc> doko: will do, want to make sure the build works fine, then will file, is it ok if i use the bug report that was already filed requesting we pull in the debian fixes?
[23:48] <nacc> Pharaoh_Atem: around?
[23:52] <stefanct> oh wow... s390 O_o why was that added? :)
[23:53] <sarnold> because someone wants to sell them :)


[00:47]  * gwolf looks around
[00:47] <gwolf> Oh! an +o!
[00:48] <jawnsy> very nice
[00:48] <jawnsy> oh, me too
[00:48] <nhandler_> gwolf: Just preparing for the session. You guys still have ~10 minutes
[00:48] <gwolf> ok
[00:48] <gwolf> you do the signalling.
[00:59] <jawnsy> Hi everyone
[00:59] <jawnsy> It looks like it's about time for the Packaging Perl Modules session
[01:00] <jawnsy> Hopefully some of you are here for the talk, or gwolf and I will be talking to ourselves :-)
[01:00] <gwolf> Yup - 2:00AM according to me, so we are ready to start!
[01:00] <jawnsy> If you've got a question, feel free to ask whenever. I only ask that you try to keep questions relevant to the thing currently being discussed, just so the logs don't get too confusing
[01:00] <gwolf> nhandler: So, you are the guy who invited us. Should we expect anything from you?
[01:00] <gwolf> or should we just address The Audience?
[01:00] <maddeth> 1am by me :p but dont know how long I will be here
[01:01] <nhandler> gwolf: You guys are in charge now ;) I'm just here for the show now
[01:01] <gwolf> good :)
[01:01] <jawnsy> Okay, so a quick introduction
[01:01] <gwolf> ok, so lets al just welcome and listen to jawnsy
[01:01] <ajmitch> most people will probably remain quiet :)
[01:01] <gwolf> I have this (annoying?) tendency of having a hard time to sit and listen at an audience, I always end up interrupting
[01:01] <jawnsy> gwolf and myself are members of the Debian pkg-perl team, gwolf is a Debian Developer, and I am not
[01:01] <gwolf> so I'd rather interrupt jawnsy rather than myself ;-)
[01:02] <jawnsy> We're going to do this talk under the assumption of no previous knowledge making any packages, either for Ubuntu or for Debian
[01:02] <jawnsy> Luckily, packaging Perl modules is pretty gentle. A few tools you will need frequently are: dh-make-perl, lintian
[01:03] <gwolf> That's basically thanks to that the Perl modules all share a basic infrastructure
[01:03] <jawnsy> I'm going to go through packaging a small module from CPAN, we'll discuss what commands you can use to do it
[01:03] <jawnsy> first of all, in order to follow along you'll need to apt-get install the aforementioned tools
[01:03] <gwolf> ...And that's also the main reason we (a group of ~15 people at most) can keep up with ~1300 packages in a reliable way!
[01:04] <maddeth> aptitude installing now :)
[01:04] <jawnsy> Another useful package is devscripts, which contains "debuild" -- a command we'll be looking at later
[01:05] <jawnsy> While everyone's installing that stuff, is there a particular module anyone would be interested in using as an example?
[01:05] <gwolf> jawnsy: oh, catalyst could be a good example
[01:05] <jawnsy> Otherwise I'll just pick one at random
[01:05] <gwolf> (of something you want to avoid ;-) )
[01:06] <gwolf> lets start simple, with something not dependency-rich
[01:06] <Ryan52> Locale-Msgfmt
[01:06] <Ryan52> no dependencies other than Perl core, and it should "just work".
[01:07] <jawnsy> okay
[01:07] <jawnsy> So, make a directory and change into it (the build process might clutter your directory with some files, so it's best to put it somewhere). I usually make a bunch of directories like 'tmp'
[01:08] <jawnsy> the first command you want to run is: dh-make-perl --cpan Locale::Msgfmt
[01:08] <gwolf> jawnsy: Let me fill in a minute please :)
[01:08] <jawnsy> Hopefully you have CPAN configured, otherwise it might ask you to configure it. Usually just hitting enter all the way down will be OK
[01:09] <gwolf> I think we have a bit different approaches - I think it's a bit better to first introduce what is _about to_ happen ;-)
[01:09] <gwolf> But anyway - Yes, dh-make-perl is a magic script
[01:09] <gwolf> ... In preparing Debian packages, you will see lots and lots of dh_* calls - To the debhelper scripts
[01:10] <gwolf> dh-make-perl is _NOT_ part of debhelper, but extensively uses i
[01:10] <gwolf> it
[01:10] <gwolf> ...Anyway... Ok, I agree with jawnsy's reasoning (which was sent to me out of band)...
[01:10] <gwolf> ...so I'll let him continue with the demonstration
[01:10] <gwolf> we can later talk about pedagogy ;-)
[01:11] <jawnsy> debhelper, as you may or may not know, is a collection of scripts that Debian uses to build and install packages
[01:11] <jawnsy> prior to debhelper, we were using huge makefiles.. which, as you can imagine, gets pretty hard to maintain and debug
[01:12] <jawnsy> Once you do dh-make-perl --cpan Locale::Msgfmt, you should see a bunch of text scroll by your screen, how it's unpacking a tarball
[01:12] <jawnsy> Most importantly, at the end, you should get a line that says "--- Done" which meant everything went OK
[01:12] <jawnsy> For those following along with this, please confirm that you can build using dh-make-perl. If not, mention any problems you are having in #ubuntu-classroom-chat
[01:13] <jawnsy> Okay.  Let's look at what it created.
[01:14] <jawnsy> cd into Locale-Msgfmt-0.14, and list the directory's contents
[01:14] <jawnsy> Everything in that directory is from the tarball we just downloaded from CPAN
[01:15] <jawnsy> what is important to note for us is the files in debian/, which basically tell our installer (debhelper) how to do its magic. It also contains metadata files that tell Aptitude how to resolve dependencies, for example
[01:15] <jawnsy> I'll go through these files (in debian/) file-by-file so we can look at what they are for.
[01:16] <jawnsy> While dh-make-perl is great at its magic, it's also not perfect. So we have to manually check that everything is OK and makes sense.
[01:16] <gwolf> Just as a sidemark - often, dh-make-perl's generated files are good enough for straight _local_ use
[01:17] <gwolf> that means, if you just install them, you can basically trust they will not eat your hard disk, and will even behave
[01:17] <jawnsy> Oh, yes. If you are building Perl modules for your own consumption, they are often good enough to install right away. You can use: dh-make-perl --install --cpan Locale::Msgfmt for that purpose
[01:17] <gwolf> of course, if you are interested in contributing Debian or Ubuntu, a human should check it!
[01:18] <jawnsy> Often doing this is better than using the CPAN shell to do installs, because this way you can remove packages easily
[01:18] <jawnsy> the debian/compat file just contains the version of debhelper that the module is built for, in this case it should just contain "7" on its own line, which means it's designed for the debhelper 7 series
[01:19] <gwolf> And IIRC, dh-make-perl will not by default work on modules that are marked as unstable by their authors, just on the highest official release (which can be otherwise using the CPAN shell)
[01:19] <maddeth> cat compat
[01:19] <maddeth> lol
[01:19] <jawnsy> yep, it's small :-)
[01:19] <maddeth> oops ;)
[01:19] <gwolf> maddeth: Yup - debhelper uses lots of small files. You will find several such files with minor indications
[01:19] <jawnsy> Now, look inside the 'control' file
[01:20] <jawnsy> I'll briefly discuss some important points, but to get the full idea of what's going on, reading the Debian Policy Manual is the best way
[01:21] <gwolf> right - we got reminded that you might be looking at some possibly different things
[01:21] <gwolf> i.e. if you are running the latest stable versions, or even more if you are using the LTS releases, you will -of course- face older results. Specially LTS will generate a _very_ different set of results (although should be equally usable)
[01:22] <gwolf> but anyway, please ignore such small inconsistencies
[01:23] <jawnsy> Mhm. Basically, this d/control file is what tells aptitude/synaptic various things which you might see as familiar. This is where a package description is defined, among other things
[01:24] <gwolf> debian/control basically lays out all the metainformation - What packages does this one depend on? What is it about? Who created it? ± when? (while it does not contain the dates, as we will go over that soon, it has a rough indication on when it was last updated: its standards-version)
[01:24] <gwolf> ..and several other, less interesting details
[01:25] <gwolf> Note that even if you are working with Ubuntu... at the package source level, keep in mind it will always be debian/*
[01:25] <jawnsy> oh, when I say d/control, I should note that it's a short form (in discussion) for saying debian/control
[01:26] <jawnsy> we get used to that slang a lot in pkg-perl
[01:26] <gwolf> For this module (or package, depending on which side of reality you are standing), the information in debian/control is quite minimal - but were you to build a more involved package, it can... grow quite a bit
[01:26] <gwolf> heh, in Debian in general, and I guess it also happens in Ubuntu :)
[01:26] <jawnsy> Yes, right now, it only contains two sections (things separated by a newline)
[01:27] <jawnsy> the top part refers to the "source package", the second part refers to binaries generated from the source package. None of that matters right now, so don't worry about it
[01:27] <jawnsy> Okay, onto the next file. You should see a file called: liblocale-msgfmt-perl.docs
[01:27] <jawnsy> and a similar one with the extension .examples
[01:27] <jawnsy> cat these and take a look at them. You'll notice it's just a line-separated list of filenames and paths
[01:28] <gwolf> some of this files might not exist under some circumstances - they depend on what is included on each of the modules you work on
[01:28] <jawnsy> These are magical files, and they trigger debuild to "install" them. Note that anything listed in these files will be installed on Ubuntu and Debian systems which install your package.
[01:28] <jawnsy> Basically, .docs is a way of listing some files which are useful for users to read, so they'll be installed on your system.
[01:29] <gwolf> And, of course, they are autogenerated - so it is possible you will find some examples or files missing. Feel free to just create them with the filenames (relative to the source package's root) for whatever files you want treated as such.
[01:29] <jawnsy> It should list a single file, README, for this package
[01:29] <jawnsy> take a look at the contents of README. you'll notice that it doesn't really say anything interesting.
[01:30] <jawnsy> just the usual stuff like how to install the package manually. this sort of thing isn't tremendously useful to our users, so you can remove the README entry from the .docs file
[01:30] <jawnsy> now, it's no use keeping an empty .docs file around, so since there's nothing we need to install, you may simply rm the .docs file
[01:30] <gwolf> In fact, it could be (and was, several releases ago) simpler: debhelper is quite flexible. here, the filenames are prepended by the package name (liblocale-msgfmt-perl.docs i.e.) - If you were to add other binary packages generated by the same source, they would not be included. you could just name them "docs" and "examples", and the results would end up in all generated files.
[01:30] <gwolf> sorry, all generated binary packages
[01:31] <jawnsy> Is everyone following with us here?
[01:31] <maddeth> could you just remove the *.docs file altogether? or is it a requirment?
[01:31] <jawnsy> You can remove the .docs file if it's empty
[01:31] <gwolf> You can of course remove it if there are no docs to install
[01:31] <jawnsy> And you should.
[01:32] <jawnsy> Okay, the next file to look at is 'rules'
[01:32] <jawnsy> Some of you in the audience might notice that it looks an awful lot like a makefile.
[01:32] <jawnsy> Well, it is :-)
[01:32] <jawnsy> (and is in fact processed by GNU make)
[01:32] <gwolf> Documentation is usually installed to /usr/share/doc/<pkgname>, and examples /usr/share/doc/<pkgname>/examples.
[01:33] <gwolf> jawnsy: In fact, there was a discussion some months (years?) ago in Debian, as to whether debian/rules needed to be a Makefile or could be something else
[01:33] <gwolf> in theory it would work just if it had the proper shebang to anything other than make
[01:33] <gwolf> in the end it was left as a GNU make file fo... consistency
[01:34] <jawnsy> syntactically, makefiles are pretty easy to work with. there's not too much you need to know to work with a makefile.
[01:34] <gwolf> heh, at first sight don't try to make _much_ sense out of debian/rules
[01:34] <jawnsy> depending on the version of dh-make-perl you have installed, you might get files of various length.
[01:34] <gwolf> It basically means: "For every target, call the suitable dh helpers"
[01:34] <gwolf> oh, right!
[01:34] <gwolf> Well, for the latest versions, using the short DH7 variant, it basically says:
[01:34] <jawnsy> Just remember that the rules file you have is what tells debhelper how to build and install your package, and how to clean up after itself
[01:34] <gwolf> #!/usr/bin/make -f
[01:34] <gwolf> %:
[01:34] <gwolf> 	dh $@
[01:35] <gwolf> But we used to generate a ~50 line debian/rules until recently.
[01:35] <jawnsy> that's a new shorthand debhelper has, which makes working with and maintaining packages that much easier, especially Perl ones
[01:35] <jawnsy> the last file we haven't looked at yet is watch
[01:36] <jawnsy> you don't need to care that much about that one. It's just a way for Ubuntu and Debian to automatically look for new upstream versions
[01:36] <jawnsy> because everything is on the CPAN, dh-make-perl sets that up for us :-)
[01:36] <gwolf> it basically consists of an URL and a pattern to look for in its webpage
[01:36] <jawnsy> this way, some commands that use it, such as uscan (in package devscripts, which you should've installed by now)
[01:37] <jawnsy> can make use of the information therein. It doesn't really matter for now :-)
[01:37] <jawnsy> okay, so, now that we know what all these control files are doing, change back to Locale-Msgfmt-0.14 (the root of your package)
[01:37] <gwolf> but you can try, just for the sake of it: Run "uscan --verbose"
[01:38] <jawnsy> ah, good point gwolf :-)
[01:38] <gwolf> :)
[01:38] <jawnsy> okay, now, to actually build this package into the binary .deb files we are used to seeing
[01:38] <gwolf> anyway, jawnsy... you were picking up your magic wand
[01:38] <gwolf> please perform the trick
[01:38] <gwolf> note that I have my hands firmly tied behind my back and cannot move.
[01:39] <jawnsy> Make sure you have the 'dpkg-dev' package installed
[01:40] <jawnsy> this is a collection of programs you'll need to build .deb binaries
[01:40] <jawnsy> there are two commands we can use to start the build, either debuild or dpkg-buildpackage
[01:41] <jawnsy> it will display a lot of output. if you've ever installed a CPAN module in the past, you'll note that the output looks mostly the same
[01:41] <jawnsy> this is because the debhelper process is actually running the Perl build system -- that is, running Makefile.PL or Build.PL
[01:42] <jawnsy> Is anyone having problems with the build?
[01:42] <jawnsy> if you do a ls of your current working directory, you'll note that there are some intermediate build files. this is because debhelper built the module and hasn't cleaned up after itself
[01:43] <jawnsy> in order to restore everything back to the "clean" state, run the command: debian/rules clean
[01:43] <jawnsy> or 'debclean'
[01:43] <maddeth> sorry jawnsy where do we run dpkj-buildpackage? the debian directory?
[01:43] <gwolf> you can run it from the base package directory
[01:43] <jawnsy> you want to run it in the root directory of the module, so in this case, Locale-Msgfmt-0.14
[01:43] <maddeth> thankyou
[01:44] <gwolf> (you will notice my hands have been untied and you have some shiny new packages ready!)
[01:44] <jawnsy> the reason for that is that dpkg-buildpackage looks for files in debian/* under the base directory
[01:44] <jawnsy> once you have done the build, change to the directory *above* the base directory (this is why I told you to make a temporary directory at the beginning)
[01:45] <jawnsy> you should notice a bunch of files there. Most importantly to this process is the .deb file, which was magically built for you by dpkg-buildpackage
[01:45] <gwolf> In fact, we could have got to this precise place even in a more automated way to begin with :-) If we had specified the command «dh-make-perl --build --cpan Locale-Msgfmt», the package would have been built and left in our currently working directory. Many times I have done that.
[01:45] <jawnsy> if you so desire, you can install it on your system using: sudo dpkg --install liblocale-msgfmt-perl_0.14-1_all.deb
[01:46] <jawnsy> but, how do we know what it's going to install? how can I be sure it won't overwrite some really important files?
[01:46] <gwolf> Well, to begin with... The dpkg package management system would refuse!
[01:46] <dam> gwolf: but you would miss the cleanup of .docs
[01:46] <jawnsy> quite conveniently, dpkg provides a "--contents" command
[01:46] <gwolf> dam: Of course. But for local builds, that's often enough :)
[01:46] <jawnsy> so that we can basically list the files inside our binary, and more importantly see *where* files will be installed
[01:47] <gwolf> (you'd even miss the warm feeling from having a human look at it)
[01:47] <jawnsy> ok, so now, please find the .deb file which was built
[01:47] <jawnsy> and execute the command: dpkg --contents *deb
[01:47] <jawnsy> you should get a listing of files which looks a lot like some 'ls' output
[01:48] <jawnsy> this way, you can see exactly where things will install, without actually installing the binary. note that this works with any Debian (or Ubuntu) package :-)
[01:48] <gwolf> ...or, conveniently, just debc *deb
[01:48] <jawnsy> the Debian Perl philosophy is very much like the Perl philosophy -- there's more than one way to do it!
[01:49] <jawnsy> So at this time we'd like to ask the floor for any questions they might have
[01:49] <jawnsy> by now you've packaged your first Perl module, and I bet you're thinking, wow, that was easy :-)
[01:49] <gwolf> agree :)
[01:50] <jawnsy> in the Debian pkg-perl team we have more scripts which help us with this sort of thing, but right now you've got enough know-how to build Perl modules on your local machine
[01:50] <gwolf> ..and soon afterwards, we will stat talking about how to do this in a better organized way, how to contribute to your distribution, and how to be rich and famous! (or at least, how to get to travel quite a bit)
[01:50] <nhandler> How would I go about getting this module uploaded to Debian and maintained by pkg-perl ?
[01:50] <nhandler> ;)
[01:50] <jawnsy> That, is quite a good question.
[01:51] <jawnsy> OKay let me dispel some myths first of all
[01:51] <jawnsy> Many people seem to think that in order to contribute to Debian or Ubuntu, you've got to be a Debian Developer, or a Ubuntu Developer
[01:51] <jawnsy> the pkg-perl team is a great way to get involved in both Debian and Ubuntu
[01:51] <gwolf> good!
[01:52] <jawnsy> and best of all, you don't need to be a full-fleged Developer
[01:52] <gwolf> In fact, it is a great way to check how your packaging is, and have other people do the heavy lifting
[01:52] <gwolf> ...Our team, as I said earlier, has around 15 active members (from a much larger list).
[01:52] <jawnsy> Basically, under the pkg-perl team, we maintain all our packages as a group
[01:53] <jawnsy> It's nice because if you ever get stuck, you have a great support network of people to ask for help
[01:53] <gwolf> Of course, to be able to become active in it, you should at least know the basics of Perl and Debian packaging, and be interested and willing to work on any potential bugs
[01:53] <jawnsy> And, more importantly, it's never hard finding a sponsor -- many Ubuntu and Debian developers are part of the group :-)
[01:53] <gwolf> (hold a second for me, we are being moved to a different laboratory)
[01:53] <jawnsy> maddeth: how did your build go?
[01:53] <maddeth> flawlessly thankyou
[01:54] <maddeth> just running a few things through my head :)
[01:54] <jawnsy> Please folks, if you have questions, feel free to ask. And if you're packaging something for your own use later and you come across something else, feel free to join our group channel and ask us
[01:54] <jawnsy> the pkg-perl group sits on IRC at irc.debian.org (OFTC) #debian-perl
[01:55] <gwolf> ready
[01:55] <jawnsy> If you're looking for a way to really make your mark on Debian or Ubuntu, please join the group. You don't need any prior experience to join the group
[01:55] <gwolf> ok... So in order to work on this group, there is a couple of things to add to your skillset
[01:55] <gwolf> First of all, as I said, we collectively maintain ~1300 packages
[01:56] <gwolf> The best (only?) way we can do this is to coordinate it via a version control system
[01:56] <gwolf> that ensures we all share each other's package modifications - And we use SVN (Subversion) for it
[01:57] <gwolf> Before anybody asks - there has been talk regarding how to move our workflow towards the much more agile and flexible Git
[01:57] <gwolf> ..We will get to it, sooner or later.
[01:57] <jawnsy> having things in subversion or any VCS really.. is indispensible
[01:57] <jawnsy> for example I could ask gwolf to take a look at something for me and help me figure out why it's not building
[01:57] <gwolf> And taht also allows us to do transversal, large-scale updates
[01:58] <gwolf> i.e. if we were to decide to, say, change some part of our build process, we could run it from one single place, for all of our packages
[01:59] <gwolf> of course, we would have to do each change separately (i.e. via a script), but it would be grouped into one logical entity - into a single commit.
[01:59] <gwolf> Anyway - where to look for this information?
[01:59] <jawnsy> Seriously, if you've got some free time and a passion to learn something new, I would really recommend joining the group
[02:00] <gwolf> Well, the main pointer holder is at the group's (very basic!) page: http://pkg-perl.alioth.debian.org/
[02:00] <gwolf> This page just holds pointers to our inside bits
[02:00] <gwolf> I would read them (and refer to them) in +- the following order:
[02:00] <jawnsy> The great thing about Open Source is that if you want something, you can just dive in and do it yourself
[02:01] <jawnsy> I myself have 91 packages in Debian's main repository, and like I said, I'm not a Debian Developer :-)
[02:01] <gwolf> - How does this group use Subversion? http://pkg-perl.alioth.debian.org/subversion.html   (includes a short guide on a great tool we have, which is indispensable for our work: svn-buildpackage)
[02:01] <jawnsy> it's a great way to get some experience working on Debian and Ubuntu. It's a great way to enhance your system
[02:01] <jawnsy> actually being part of the group, I come across a lot of really neat modules while packaging them
[02:01] <jawnsy> so it's useful in that sense too
[02:02] <gwolf> - The Perl packaging policy: http://pkg-perl.alioth.debian.org/policy.html
[02:02] <gwolf> jawnsy: That's really true. And you never know who will be the next person to show you something new
[02:02] <jawnsy> plus, I've met some really nice people in the pkg-perl group that I am honoured to call my friends
[02:03] <gwolf> - General tips and tricks: http://pkg-perl.alioth.debian.org/tips.html
[02:03] <jawnsy> joining the group is a huge plus if you're looking to get some experience coding
[02:03] <jawnsy> we do a lot of things in the group which are transferable skills
[02:03] <jawnsy> for example managing the bug system, dealing with other people, discussing new ideas
[02:03] <maddeth> thankyou for the tutorial, I need my sleep now :)
[02:04] <gwolf> http://pkg-perl.alioth.debian.org/cgi-bin/pet.cgi - possibly the best reference point we have towards the current status of all of our packages
[02:04] <gwolf> (looking for quilt's...)
[02:04] <gwolf> http://pkg-perl.alioth.debian.org/howto/quilt.html
[02:05] <gwolf> This last one: Not very often, we will have to patch (modify) the author's code in order to route around a problem
[02:05] <gwolf> The best way to do so, keeping everything most traceable, is using the Quilt patch management system.
[02:06] <gwolf> jawnsy: dam (in #debian-perl) is most right! We forgot one of the most important files to check: debian/copyright
[02:06] <jawnsy> I thought that'd be a bit too much for a gentle introduction
[02:06] <gwolf> debian, and Ubuntu (although to a smaller degree) really base their work on respect to Free Software
[02:07] <gwolf> in order for a package to be built (and yes, this time it _is_ a requirement), it has to list its copyright information
[02:07] <gwolf> debian/copyright is a human-readable (and increasingly, machine-readable - but that's not necessarily yet a given) file explaining which licensing scheme does this particular package follow
[02:08] <gwolf> Most usually, Perl modules are licensed "under the same terms of Perl itself"
[02:08] <gwolf> that means, under the GNU GPL 1 or any posterior version or under the Artistic license, at your choice
[02:08] <gwolf> so, yes, this has to be listed in debian/copyright
[02:09] <gwolf> jawnsy: so... where should we go from here? At 03:10, my brain is drying, and I think I'd appreciate some Q&A
[02:09] <jawnsy> increasingly a lot of companes are working with Debian and Ubuntu
[02:09] <jawnsy> so joining the group and learning the ins and outs of maintaining packages could very well help you land a sysadmin-type job
[02:10] <gwolf> of course - it is highly visible, permanent professional information you can talk about
[02:10] <jawnsy> a lot of companies use locally build packages for distributing and updating even internal packages for distribution to their production servers
[02:11] <jawnsy> but yes, I'd like to open the floor to any questions
[02:11] <gwolf> so, people... is there any of you awake+online? :-}
[02:11] <gwolf> Are there any questions?
[02:11] <gwolf> There is a lot of where to go on... but I think we have mostly covered the basics
[02:12] <nhandler> So if I am not a Debian Developer, how could I get my package uploaded? Would I need to go through mentors.debian.net ?
[02:12] <jawnsy> If you are reading the log of this talk later on, and you have questions, feel free to come on irc.debian.org #debian-perl and ask :-)
[02:12] <jawnsy> That is a very good question :-)
[02:12] <gwolf> nhandler: no, not necessarily
[02:12] <jawnsy> just by joining the pkg-perl team, you can skip the mentors process if you desire
[02:12] <gwolf> nhandler: If the package is a Perl one, going through mentors would certainly be among the slowest ways possible
[02:12] <gwolf> The first thing to do is to get an Alioth account
[02:13] <jawnsy> personally, like I say I'm not a DD, I've never uploaded a package through a mentor
[02:13] <jawnsy> the purpose of a mentor is to review your package and help you with building it, fixing up the necessary control files, and uploading it
[02:13] <gwolf> Alioth (http://alioth.debian.org) is Debian's online collaboration subsystem, it is a GForge-derived site
[02:13] <jawnsy> thankfully, the DD sponsors in our group serve the same purpose
[02:14] <gwolf> Alioth is open to DDs and non-DDs, with the sole difference that you will have '-guest' appended to your login in case you are not a DD (yet?)
[02:14] <jawnsy> they also teach newcomers how to build Debian Perl packages (similar to what we've discussed here today, but also covering some rarer cases)
[02:14] <gwolf> But yes, it is common to find a newbie in the #debian-perl group asking how to join and what to do
[02:14] <jawnsy> we are a rather informal group.. more of a collection of friendly people
[02:15] <gwolf> nhandler: So, to round your question: You request an Alioth account and svn-inject your package
[02:15] <gwolf> nhandler: ...We will notice it and build it, usually soon
[02:16] <jawnsy> working with our SVN workflow is a totally different lecture for a different day, but it's not hard. we have tools, like svn-inject as gwolf mentioned, that help us do it
[02:16] <gwolf> oh, of course, you have to request to join the pkg-perl group once you have your Alioth account
[02:16] <jawnsy> anyway, barring any other questions, it looks like we can draw this talk to a close
[02:17] <nhandler> You mentioned that you maintain ~1300 packages. How do you keep track of which ones need to be updated, and which have bugs?
[02:17] <jawnsy> We have a tool (yay, another tool) called the Package Entropy Tracker
[02:17] <gwolf>  http://pkg-perl.alioth.debian.org/cgi-bin/pet.cgi
[02:17] <jawnsy> ah I was finding the link, beat me to it gwolf :-)
[02:17] <gwolf> :)
[02:18] <jawnsy> as you can see from the page, it lets us know what we need to fix -- packages with really important bugs, packages with new upstream versions (that's what the watch file was about)
[02:18] <jawnsy> and it allows us to collaborate as a group -- so for example I don't do something to a package gwolf is working on
[02:18] <jawnsy> (otherwise one of us would be doing double work)
[02:19] <gwolf> The IRC channel is a great place to hang out (and I very seldom join any IRC channels - But this one is actually productive!)
[02:19] <nhandler> So does that mean that I can work on any package maintained by pkg-perl? Even if someone else packaged it?
[02:19] <jawnsy> generally, yes it does. If you want to dive in, feel free to do so!
[02:19] <gwolf> Of course. Every now and then people appear. And some others disappear
[02:19] <gwolf> And even if no one does - If I find a package that needs love, and have love to give, I will work on it
[02:20] <jawnsy> it's a really great way to get experience working with Perl modules, but in a less aggressive way than writing ones for CPAN
[02:20] <gwolf> Usually, whenever you update a package, you will add yourself as an uploader to it (which means, claim responsablity for its maintenance)
[02:20] <jawnsy> for example we do a lot of Quality Assurance stuff, like fix outstanding bugs
[02:20] <jawnsy> one great thing about our package system, and as gwolf mentioned earlier, quilt... is that we can ensure good QA
[02:20] <jawnsy> by fixing modules ourselves if necessary.
[02:21] <gwolf> ...and more easily push the changes up to the authors
[02:21] <jawnsy> so let's say there's a serious security issue with a package. well, in Debian we can just patch it ourselves, and push out a new release, while simultaneously working with the upstream author to resolve the issue
[02:21] <jawnsy> in that way, Debian and Ubuntu users are safe, even if the Upstream maintainer doesn't know about or doesn't fix a package
[02:22] <jawnsy> actually a lot of upstream CPAN authors sort of just abandon their stuff, so the pkg-perl team takes care of its long-term maintenance
[02:22]  * gwolf yawns
[02:22] <gwolf> people, any questions?
[02:22] <jawnsy> it's something I think is tremendously useful experience
[02:22] <jawnsy> just how to debug things, how to work with bug systems
[02:22] <gwolf> If you don't fire...I'll go to sleep!
[02:22] <jawnsy> these are things you often won't learn in school, but that can make all the difference in your career
[02:22] <jawnsy> whether you hit the ground running or whether you'll have to start crawling ;-)
[02:22] <gwolf> I completely agree with jawnsy
[02:23] <gwolf> Anyway... jawnsy: I think we should call this as done
[02:23] <jawnsy> yep. thanks everyone for listening, I hope it's been a good experience for everyone
[02:23] <gwolf> jawnsy: nhandler says the logs will be available
[02:24] <gwolf> I hope you found this interesting, and hope to have you on board on the team!
[02:24] <nhandler> Logs will be at https://wiki.ubuntu.com/Packaging/Training/Logs/2009-07-23
[02:24] <nhandler> Thank you jawnsy and gwolf for leading this session
[02:24] <porthose> jawnsy gwolf, thx  great session
[02:24] <gwolf> thank you for inviting!
[02:24] <nhandler> Remember, if you have and questions, the pkg-perl team is in #debian-perl on irc.debian.org
[02:24] <jawnsy> and if you're at DebConf you can have a beer with gwolf :-)
[02:25] <jawnsy> thanks to the Ubuntu community for having us, and for working so closely with Debian to the benefit of both communities
[02:25] <gwolf> jawnsy: And with dam, and with gregoa, and with diocles!
[02:25] <gwolf> Thank you all, even if you removed our Op modes ;-)
[02:26] <jawnsy> I really hope you all take the opportunity to be a bit social.. feel free to drop by just to say hi, even :-)
[02:26] <jawnsy> the Ubuntu and Debian projects are both highly social, so I hope you all take the chance to participate everywhere you can, when you can
[02:26] <gwolf> jawnsy: And by all means, specifically you, try to join a DebConf in the future!
[02:26] <gwolf> Anyway, I'm heading off
[02:26] <gwolf> nice being here, hope to see you in our little channel!
[13:55] <duaneb> I missed the chat about Packing Peel Modules last night is there a bot keeping a chat history?
[13:55] <pleia2> duaneb: the logs are here: https://wiki.ubuntu.com/Packaging/Training/Logs/2009-07-23
[13:56] <duaneb> thank you, very cool
[13:57] <pleia2> welcome :)
[20:44] <wizztjh> date -u


[12:30] <waldo323> good morning
[12:36] <rick_h_> morning
[12:45] <Scary_Guy> morning
[13:31] <jrwren> Good morning.
[13:31] <jrwren> Happy Friday.
[13:33] <rick_h_> or, unhappy friday (puking kid)
[13:33] <_stink_> :(
[13:34] <rick_h_> yea, can't wait to kick off a 12 hour drive to VA later today with him lol
[13:35] <jrwren> ewe, poor kiddo.
[13:35] <jrwren> is it spring break there?
[13:35] <jrwren> oh, next week?
[13:35] <rick_h_> yea, first day is today
[13:35] <rick_h_> he has friday -> next week
[13:36] <jrwren> ugh, what a terrible start.
[13:36] <rick_h_> so we're heading down, wife and I took half days to hopefully get down to PA and crash there
[13:36] <rick_h_> yea, no kidding.
[13:36] <jrwren> our spring break is just finishing. back to school on monday
[13:36]  * rick_h_ is grumpy about the timing
[13:36] <rick_h_> ah ok
[13:36] <jrwren> its life. Life is suffering.
[13:36] <rick_h_> cool, I was nervous about a mad dash of folks heading south on the roads today
[13:37] <rick_h_> maybe it won't be so bad if the breaks are staggered
[13:48] <jrwren> rick_h_: lol... i just got my first fountain pen :)
[13:48] <Scary_Guy> I think you mean good Friday rick_h_ :p  Also sorry to hear about your kid.  I hope it isn't that bug that's been going around.  Put two of my friends in urgent care :(
[13:48] <rick_h_> jrwren: oooh, what did you get? I love mine
[13:48] <rick_h_> Scary_Guy: bummer
[13:48] <rick_h_> Scary_Guy: yea, I forget about good friday, I guess that's today with spring break next week
[13:49] <rick_h_> I forget because good friday isn't a federal holiday
[13:49] <Scary_Guy> yeah, and I hung out with one Tuesday and another one this morning.  I don't generally get sick though and I've had my shot but I guess this is a different strain.  still I'm not too worried
[13:49] <Scary_Guy> it isn't?  one of my friends works for Chrystler and she's getting holiday pay
[13:51] <jrwren> rick_h_: oh, the absolute entry level Pilot
[13:51] <jrwren> rick_h_: nothing fancy at all. Just something ot have and use day to day.
[13:51] <jrwren> I like it, but I'm still getting learning to use it.
[13:52] <rick_h_> jrwren: cool, yea I fell down the rabbit hole. I've got 7 or 8 inks, handful of pens, different sizes/etc
[13:54] <rick_h_> jrwren: the lamy ones are nice cheap little daily drivers that folks can borrow and such
[13:54] <rick_h_> that's the only one I have that takes the inserts
[13:55] <jrwren> yeah! I was happy about the inserts TBH, becuase I didn't want to mess with the ink.
[13:55] <jrwren> those cartriges make it very nice and easy.
[14:02] <rick_h_> yea, works well
[14:09] <rick_h_> Rocket launch time https://www.youtube.com/watch?v=mp0TW8vkCLg
[14:18] <jrwren> SpaceX is cool.
[14:18] <jrwren> another launch successful so far.
[14:19] <Scary_Guy> I can't wait until they stop doing these, because it's become that ubiquitous and mundane since it's a part of daily life
[14:19] <Scary_Guy> I mean they don't video every airplane takeoff/landing
[14:20] <jrwren> the 9min blackout is because of aliens.
[14:20] <jrwren> Scary_Guy: there is nothing ubiquitous or mundane about the reuse being done by spacex.
[14:20] <Scary_Guy>  I like how two different people on two different networks mentioned this too
[14:21] <Scary_Guy> I know, I mean I can't wait until we get to that point
[14:21] <rick_h_> jrwren: lol
[14:21] <jrwren> this is the first time ever they are attempting to reusing the 6M$ fairing, which is the only reason I am interested in this particular luanch.
[14:22] <rick_h_> I want to see them try to catch the faring, that's crazy
[14:22] <rick_h_> at least the first stage can steer
[14:22] <jrwren> Yes, I agree. It really hope things get reusable and inexpensive and we look back at the 80s and 90s and 00s and think WTF?
[14:23] <rick_h_> hah, "how much was that space shuttle? You all built a space station with that thing?"
[14:23] <rick_h_> this will one day be the go to for "sometimes you have to take a step back to move forward" heh
[14:24] <rick_h_> jrwren: you'll appreciate this, http://info.crunchydata.com/blog/postgres-operator-for-kubernetes
[14:24] <rick_h_> jrwren: so they wrote a charm for postgres on k8s that has its own cli client lol
[14:24] <jrwren> wow. crazy.
[14:24] <jrwren> this is where k8s goes crazy IMO. But I guess, I'm pretty crazy too.
[14:25] <rick_h_> yea, I was following some threads around coreos providing "operations for k8s deployed software" and got here and that's enough lol
[14:26] <jrwren> i guess with k8s getting better managed storage this kind of thing kind of makes sense.
[14:27] <jrwren> you can think of your k8s as a resource limiter and exposing db config like this via k8s api does have some advantages, but i feel like just running a DB in a more conventional cloud config makes more sense most of the time.
[14:33] <rick_h_> I like seeing the ack that operations goes beyond install and upgrade
[14:35] <jrwren>  listen to this one with sound.  https://twitter.com/cabel/status/979097369936502785
[14:36] <jrwren> too true, rick_h_, in fact, k8s is so fast moving right now i feel like there is too much ops just for the k8s cluster.
[14:36] <rick_h_> I'm floored trying to get stuff to work. "Just write out these 12 yaml files and these commands and viola...you've got your running software"
[14:37] <jrwren> hahahaha.
[14:37] <rick_h_> ok, listened with sound...I don't remember these with floppies. Song isn't really good
[14:37] <jrwren> well, process based containers does mean there are no system to deal with.
[14:37] <jrwren> rick_h_: you don't recognize the song?!? oh shit, maybe i'm too lold.
[14:37] <rick_h_> no, I don't recall it atm
[14:37] <jrwren> that is canyon.mid, a midi file that shipped default with windows 95.
[14:38] <rick_h_> ah, did have/run win95 (my first own computer OS that I swapped with NT back and forth)
[14:38] <rick_h_> but don't recall that midi file, I didn't mess with sound much on computers until winamp/mp3
[14:38] <rick_h_> games I guess
[14:38] <jrwren> ah, ok. yes, will in '95 that was the song on all windows computers.
[14:39] <rick_h_> gotcha
[14:52] <Scary_Guy>  Start me up or that one Weezer song that was also on the CD?
[14:53] <Scary_Guy> actually I think it was the video
[14:53] <jrwren> yes, it was.
[14:53] <jrwren> Buddy Holly video by Weezer
[14:54] <jrwren> and... after chatting with someone else about canyon.mid. I sit corrected. It was shipped with windows 3.1, so 1991.
[14:54] <jrwren> A bit older.
[14:54] <rick_h_> ah, yea that's before my time
[14:54] <rick_h_> I didn't get my own computer until college so I missed a lot of early stuff
[14:55] <jrwren> I got a job fixing PCs at a store in '95 a few months before win95 came out, so I got to see a lot of stuff.
[14:55] <Scary_Guy> I got my first one at 9, but used the old Apple IIe in preschool
[14:56] <Scary_Guy> but still no internet until 98 was stunting
[14:57] <Scary_Guy> I think around 99 I was waking up and getting on the PC, going to school to get on the laptop, going to work to fix systems, and going back home and working on it until 2AM
[14:57] <Scary_Guy> after a while I got burnt out a bit, then got back at it
[14:57] <Scary_Guy> like six months of that
[14:57] <jrwren> good times!
[14:57] <Scary_Guy> now I just want my computer<>brain interface
[14:58] <Scary_Guy> waiting for science to catch up to sci-fi is grueling
[15:03] <cmaloney> God, those great Roland MIDI sounds
[15:03] <cmaloney> I don't think I remember seeing that machine either but it makes perfect sense
[15:04] <cmaloney> Seems like one of those specialty devices that you'd take to band practice to show off some midi wankery you did without bringing the whole kit
[15:04] <cmaloney> which would probably appeal to about 10 people
[15:05] <cmaloney> https://www.youtube.com/watch?v=5ks3ucumilU
[15:06] <cmaloney> Music Tutor. So it's for learning
[15:31] <rick_h_> Woot got the hello installed finally https://photos.app.goo.gl/Z1ai6bHf9DkZkCwA2
[15:40] <cmaloney> nice!
[15:40] <rick_h_> yea, fun to get it installed and tonight leave for VA
[15:40] <rick_h_> so can spy on the house while away
[15:40] <cmaloney> Heh
[16:13] <Scary_Guy> I would be one of those people
[16:14] <Scary_Guy> learning not to suck, lol.  also I love that guy's channel
[16:14] <Scary_Guy> nice
[16:15] <Scary_Guy> I need to do something similar, the remote talk feature looks sweet though too
[16:15] <Scary_Guy> in fact I think I'll try making hooking up that camera today's project.  bbl
[16:29] <jrwren> hehe, cool. that lens looks nice.
[16:29] <jrwren> someoen else had a doorbell without the aspect lens recently and it looks really weird
[16:58] <rick_h_> yea, looks a bit better now that I've gotten into the settings and upped the quality
[17:01] <rick_h_> looks like about 1/4 or 1/3 less bandwidth than the outdoor camera
[17:03] <jrwren> whoa, that is really good.
[17:03] <rick_h_> I wish I could wedge it out a little bit more
[17:03] <rick_h_> only has the one mount place that angles it 15deg
[17:03] <rick_h_> mount plate that is
[17:03] <rick_h_> well it's .3-.4Mbps
[17:03] <rick_h_> and the outdoor one is .6-.7ish
[17:04] <jrwren> oh, that is nice and small. I htink our streams are more than that, but I'm not sure.
[17:04] <rick_h_> looking at the router at least
[22:40] <Scary_Guy> you can always mill out a new piece
[22:41] <Scary_Guy> or maybe give someone from #i3detroit the specs and have them do it


[07:10] <dholbach> good morning
[08:38] <Chipaca> mo'in
[09:03] <JamesTait> Good morning all; happy Global Beatles Day! 😃
[09:55] <Chipaca> fgimenez: gave up on cross-compiling
[09:55] <Chipaca> fgimenez: it'll be easier and quicker to build the packages 'by hand'
[09:55] <Chipaca> fgimenez: if building on the device is not an option, that is
[09:57] <Chipaca> fgimenez: now reviewing your funcitonal tests branch
[09:59] <fgimenez> Chipaca, ok np thanks a lot :)
[10:00] <fgimenez> Chipaca, i'm also exploring the cross toolchain path, no luck so far either
[10:09] <Chipaca> fgimenez: give me a shout when you want me to re-review that branch. looks mostly good.
[10:09] <Chipaca> mostly <=> needs fixing, but minor
[10:11] <fgimenez> Chipaca, ok, it'll be ready shortly thanks :)
[11:26] <Chipaca> fgimenez: you realise GOARCH will be arm, not armhf, on arm boards?
[11:26] <Chipaca> fgimenez: and 386, not i386, on i386 boards
[11:27] <fgimenez> Chipaca, yes, i've seen the function you mentioned in the helpers, it takes care of the change, do you think we should mimic it's behaviour here?
[11:27] <Chipaca> fgimenez: what are you using defaultArch for, now and in the future?
[11:27] <fgimenez> Chipaca, i mean, if we are going to execute the tests from that platforms we need to do the change
[11:28] <Chipaca> fgimenez: if it's for building the triplet or whatever it is, yes you need to do that
[11:28] <Chipaca> yeah
[11:28] <Chipaca> fgimenez: I'd say yes, then
[11:28] <fgimenez> Chipaca, ok, i'll put the function then
[11:30] <fgimenez> Chipaca, there's an arch parameter, that's what will be used for building the debs/image, right now the defaultArch helps to determine if you have to cross compile (if defaultArch != arch)
[11:30] <fgimenez> Chipaca, but indeed 386 != i386
[11:30] <Chipaca> :)
[11:31] <fgimenez> Chipaca, :) it'll be ready soon thanks!
[11:38] <sergiusens> morning
[11:38] <fgimenez> Chipaca, done
[11:39] <fgimenez> hey sergiusens
[11:40] <sergiusens> fgimenez: pretty please can you get rid of the dpkg -i from the tests? This won't work soon-ish
[11:40] <sergiusens> ogra_: feeling better today?
[11:41] <sergiusens> ogra_: if you do, mind reviewing https://code.launchpad.net/~sergiusens/livecd-rootfs/no-walinuxagent/+merge/262963 ?
[11:41] <Chipaca> sergiusens: he hasn't said a peep all day
[11:41] <sergiusens> Chipaca: he did review one of my MPs :-P
[11:41] <fgimenez> sergiusens, ok, we are carrying this from the shell version, are there any progress in the image creation from the branch?
[11:42] <ogra_> sergiusens, only partially... just returned from the dentist and i'm full of painkillers and antibiotics (they can extract the tooth only on monday once i got rid of that golfball on my jaw)
[11:42] <sergiusens> fgimenez: I am not tracking that, but we want to get rid of dpkg ASAP, even if it means breaking to not go down the path of never being able to remove it like on the phone
[11:42] <ogra_> but for a code review it will be good enough :)
[11:42] <sergiusens> ogra_: strong liquor can't get the job done wrt the pain?
[11:42] <rsalveti> ogra_: :-)
[11:42] <sergiusens> :-)
[11:43] <ogra_> sergiusens, i'll try that tonight ... ;)
[11:45] <fgimenez> sergiusens, ok, i'll put hands on it
[11:45] <ogra_> sergiusens, what if we need to re-build 15.04 stable azure images ?
[11:46]  * ogra_ guesses we need to check which livecd-rootfs is used for them ... if its the wily one that code dropping wont work but needs release checks)
[11:46] <sergiusens> ogra_: there's a livecd-rootfs in the ppa as well
[11:47] <ogra_> ah, and that is used for 15.04 builds ?
[11:47]  * ogra_ goes to check the logs
[11:48] <ogra_> Get:1 http://ppa.launchpad.net/snappy-dev/image/ubuntu/ vivid/main livecd-rootfs armhf 2.301~ppa7 [32.3 kB]
[11:49] <ogra_> looks fine then
[11:49] <sergiusens> ogra_: I was told that was the case, but confirming would be good
[11:49] <sergiusens> yay :-)
[11:49] <sergiusens> ogra_: doesn't an image build for vivid pick up the livecd-rootfs for vivid?
[11:49] <ogra_> yes, but the PPA has higher prio so it doesnt pick the one from the archive
[11:50] <sergiusens> ogra_: great, in any case this would be pushed to wily only so it doesn't really matter anyways, does it?
[11:50] <ogra_> no, it is all fine, just wanted to make sure we dont break anything for that case
[11:52] <sergiusens> \o/
[11:56] <ogra_> sergiusens, top approved
[12:01] <sergiusens> ogra_: should I get rsalveti to dput?
[12:02] <ogra_> sergiusens, nope, on it
[12:02] <sergiusens> thanks
[12:05] <sergiusens> ogra_: I might be pushing it, but here's one more ;-) https://code.launchpad.net/~sergiusens/ubuntu-seeds/no-python-for-core/+merge/262966
[12:06] <ogra_> oh, wow ... well, system-image will still pull in some python i guess
[12:06] <ogra_> (py3 though)
[12:06] <sergiusens> ogra_: python3 is still there :-)
[12:07] <sergiusens> ogra_: they are different languages, one is called python and the other python3 ;-)
[12:07] <ogra_> yeah
[12:07] <sergiusens> if they were the same, there would only be 'python' pointing to whatever version :-P
[12:11] <fgimenez> sergiusens, i've removed dpkg from https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748, the tests are built locally and copied to the testbed, let me know what do you think
[12:12] <ogra_> sergiusens, i wonder if an announcement mail would make sense before merging https://code.launchpad.net/~sergiusens/livecd-rootfs/byeByeDebbie/+merge/262786 so people are prepared
[12:54] <Chipaca> sergiusens: i get what dpkg-deb is being kept for; what's dpkg itself kept for?
[13:04] <sergiusens> Chipaca: I don't know, I know why I'm removing all others
[13:05] <sergiusens> Chipaca: and it's not that big
[13:05] <Chipaca> sergiusens: ok :)
[13:05] <sergiusens> Chipaca: and I don't want to test all over again and maybe it's due to dpkg --print-architecture
[13:06] <sergiusens> ogra_: nah
[13:06] <sergiusens> :-)
[13:06] <sergiusens> it's rolling!
[13:06] <seb128> sergiusens, ogra_, I wonder if that change should be done to ubuntu-desktop-next at the same time
[13:07] <sergiusens> seb128: well I did do this one for you guys https://code.launchpad.net/~sergiusens/livecd-rootfs/no-walinuxagent/+merge/262963 :-)
[13:07] <sergiusens> seb128: although I'm not sure why you had it in the first place ;-)
[13:07] <seb128> sergiusens, thanks ;-)
[13:07] <seb128> sergiusens, we copied the ubuntu-core hooks to start
[13:07] <seb128> so we had it because core had it :p
[13:08] <sergiusens> seb128: fair enough, wrt dpkg/apt, I don't mind replicating that to desktop next
[13:09] <seb128> I'm unsure if we decided on what we want the personal image to be
[13:09] <seb128> having apt is useful for debugging, but I guess people who want it can wget & dpkg(-deb)
[13:12] <sergiusens> seb128: I would prefer someone being encouraged to bring all these tools to a snap :-)
[13:12] <sergiusens> but whatever gets the job done!
[13:12] <seb128> yeah
[13:13] <seb128> I need to try ubuntu-core to see if /etc/default/locale is missing there as well
[13:13] <seb128> oh, and if recovery mode is working
[13:13] <seb128> on personal it just do a normal boot
[13:16] <sergiusens> seb128: we do have /etc/default/locale on core
[13:19] <sergiusens> ogra_: oh, adduser is perl...
[13:19] <seb128> sergiusens, right, you have a live-build/ubuntu-core/hooks/13-set-locale.chroot
[13:19] <seb128> unsure why we didn't copy that one
[13:19] <ogra_> sergiusens, yeah :/
[13:19] <seb128> we should ;-)
[13:20] <sergiusens> seb128: locale should probably be an ubuntu-core config thing and we should be able to set it up on first boot
[13:20]  * sergiusens creates teask
[13:20] <sergiusens> err, task
[13:20] <seb128> sergiusens, can you include keyboard layout in that?
[13:20] <sergiusens> seb128: yes
[13:20]  * seb128 is tired to type loadkeys fr after every boot
[13:20] <seb128> thanks
[13:21] <ogra_> seb128, are you doing the locale thing now ?
[13:22] <seb128> ogra_, adding the file you mean? was about to, but if you have pending commit feel free to get that done first and let me know when I can do the change
[13:22] <ogra_> seb128, well, i was about to ask if you could merge https://code.launchpad.net/~sergiusens/livecd-rootfs/byeByeDebbie/+merge/262786 along :)
[13:22] <ogra_> saves wrangling in the branch
[13:22] <seb128> ogra_, you mean adding the same diff to desktop-next?
[13:22] <ogra_> and to core ...
[13:23] <ogra_> i didnt merge it yet
[13:23] <seb128> oh, if you want sure
[13:23] <ogra_> thanks
[13:23] <seb128> yw
[13:26] <seb128> ogra_, should I wait for it to be top approved though?
[13:26] <ogra_> you can ... one sec :)
[13:26] <ogra_> *click*
[13:26] <ogra_> done ;)
[13:26] <seb128> :-)
[13:28] <olli> pardon my stupidity... if I wanted to put the snappy core image onto physical x86 HW, do I just dd the image onto the disk?
[13:29] <mvo> olli: yes or to a usb stick
[13:29] <olli> nice
[13:31] <olli> mvo, also, nw config on core/snappy ... is there any way to set a fixed IP
[13:31] <olli> not sure I saw that in the wiki
[13:31] <ogra_> just edit /etc/network/interfaces.d/eth0
[13:32] <ogra_> (defaults to dhcp usually)
[13:32] <olli> that's writable
[13:32] <olli> ok
[13:32] <olli> great
[13:32] <seb128> mvo, can you dd to a partition or does it need to take all disk? and how do you configure grub then?
[13:32] <elopio> fgimenez: meeting.
[13:33] <mvo> seb128: all disks currently, it relies on a certain partiton layout and partition labels
[13:33] <ogra_> olli, the whole dir is (in case you want to create a wlan0 or some such at some point)
[13:33] <seb128> mvo, k
[13:33] <olli> ogra_, I am covered then
[13:34]  * ogra_ nods
[13:34]  * olli is preparing the matchbox to become his home "gateway"
[13:35] <ogra_> heh, with two USB NICs ?
[13:35] <olli> hence the ""
[13:35] <ogra_> :)
[13:35] <olli> it'll be my inet accessible machine
[13:36] <ogra_> we need images for alix boards :)
[13:36] <ogra_> (my favorite home router HW)
[13:45] <ogra_> rsalveti, sergiusens, any idea why we forcefully install flash-kernel into the snappy armhf rootfs ? (nothing makes use of it in our system design or does it ?)
[14:00] <sergiusens> ogra_: no, it shouldn't be needed
[14:11] <elopio> thanks for the review Chipaca!
[14:12] <elopio> fgimenez_: lets skip our qa show today...
[14:13] <fgimenez_> elopio, ok, la hora de la calidad will be back tomorrow
[14:13] <elopio> :)
[14:14] <fgimenez_> elopio, i've added changes in https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 to remove dpkg, the tests are built locally and copied to the testbed
[14:15] <fgimenez_> elopio, seems to work good, but it's exercising the snappy shipped in the image of course
[14:16] <elopio> fgimenez_: yes, for now I would stick with the deb from trunk.
[14:16] <fgimenez_> elopio, ok, this makes cross compiling a lot easier/possible at all, i'll change that branch too
[14:19] <elopio> fgimenez_: I think I didn't explain myself correctly. I think we need to build the deb from trunk and install it.
[14:20] <elopio> but you are right that we don't need to build the deb for the tests, at least not yet.
[14:20] <elopio> fgimenez_: actually, lets go to the hangout. Sorry :)
[14:21] <fgimenez_> elopio, ok np :)
[14:43] <fgimenez_> elopio, pushed
[14:43] <elopio> fgimenez_: thank you!
[14:44] <elopio> fgimenez_: last thing, can you please remove the sudo from:
[14:44] <elopio> 315	+	infoOutput := s.execCommand(c, "sudo", "snappy", "info")
[14:44] <elopio> that was my mistake.
[14:45] <fgimenez_> elopio, sure, we can remove also the buildDebs function
[14:49] <elopio> fgimenez_: +1
[14:51] <elopio> sergiusens: ^ fixed your bzr bd problem :)
[14:52] <fgimenez_> elopio, ok, done
[14:59] <elopio> fgimenez_: bash: /tmp/snappy-test/tests/snappy.tests: No such file or directory
[14:59] <elopio> this fails because the -o of go test doesn't work.
[15:00] <elopio> I think you will have to move snappy.tests from cwd to testsDir.
[15:00] <sergiusens> elopio: go build -o does work
[15:00] <sergiusens> elopio: go build -o /tmp/snappy ./cmd/snappy
[15:00] <fgimenez_> elopio, i se it working here
[15:03] <elopio> fgimenez_: that works, but $ go test -c ./_integration-tests/tests/ -o /tmp doesn't
[15:03] <sergiusens> elopio: -o needs to be the full output file, not a path
[15:04] <elopio> sergiusens: $ go test -c ./_integration-tests/tests/ -o /tmp/snappy.test
[15:04] <elopio> doesn't work either.
[15:04] <fgimenez_> elopio, http://paste.ubuntu.com/11773748/ with the current code, the binary seems to be there
[15:05] <fgimenez_> elopio, meeting
[15:06] <fgimenez_> and Chipaca, ^
[15:06] <elopio> http://cdn.meme.am/images/84688.jpg
[15:15] <fgimenez_> sergiusens, ogra_, tedg, elopio sorry guys, trying to reconnect
[15:15] <ogra_> fgimenez_, we finished
[15:15] <sergiusens> fgimenez_: no worries, we are done
[15:15] <elopio> fgimenez_: we are done. You can give two updates tomorrow :)
[15:16] <tedg> What they said
[15:16] <fgimenez_> ok, np :)
[15:18] <elopio> fgimenez_: so, if you run this, do you get the file in tmp? $ go test -c ./_integration-tests/tests/ -o /tmp/snappy.test
[15:20] <elopio> if I do that on my two machines, I get the file in pwd. Nothing in tmp.
[15:33] <sergiusens> elopio: go test has no -o though
[15:37] <elopio> that's why I think it shouldn't work for fgimenez.
[15:38] <elopio> fgimenez: maybe you already had the test in /tmp/ ?
[15:39] <fgimenez> elopio, nope, http://paste.ubuntu.com/11773921/
[15:40] <fgimenez> here mentions the -o flag https://golang.org/cmd/go/#hdr-Test_packages, perhaps it's outdated?
[15:42] <fgimenez> elopio, what is the output of go help test for you, is the -o flag there?
[15:43] <elopio> fgimenez: http://paste.ubuntu.com/11773927/
[15:43] <elopio> I do the same and the file doesn't exist for me. You are on wily, right?
[15:43] <elopio> what's your golang version?
[15:46] <elopio> fgimenez: yes, golang test on vivid doesn't have the -o option. On wily it does.
[15:46] <fgimenez> elopio, ah! ok that makes sense
[16:03] <elopio> wow, it sucks that go doesn't have mv.
[16:03] <elopio> fgimenez: this should work for both: http://paste.ubuntu.com/11774045/
[16:07] <elopio> fgimenez: also, defaultArch, getArchForImage and ubuntuArchitecture are not used.
[16:12] <fgimenez> elopio, ok pushed, when we will have multiple tests we can parameterize this without problems
[16:14] <elopio> fgimenez: ok, looks good, thank you.
[16:56] <kyrofa> sergiusens, ping
[16:59] <sergiusens> kyrofa: pong
[17:01] <kyrofa> sergiusens, I'm not sure why I didn't notice this before, but the Snappy REST doc doesn't discuss searching. Is that something you considered?
[17:01] <kyrofa> The WebDM README discusses it in the v1 API, but that's the only reference I know about
[17:01] <sergiusens> kyrofa: yes, simple search like today; I guess I need to add it
[17:02] <sergiusens> kyrofa: do we want crazy elastic search or as it is today? (webdm and cli?)
[17:02] <sergiusens> I guess the stores elastic search gets encapsulated by the API itself in most of the cases
[17:02] <sergiusens> if not all
[17:03] <kyrofa> sergiusens, well, correct me if I'm not mistaken but all we have today is filtering by installed or package type... no?
[17:03] <sergiusens> kyrofa: no
[17:03] <sergiusens> kyrofa: http://localhost:4200/api/v2/packages/?q=hello
[17:04] <sergiusens> kyrofa: http://localhost:4200/api/v2/packages/?q=hello&installed_only=true
[17:04] <kyrofa> sergiusens, ah, I didn't know about that! Haha
[17:04] <kyrofa> sergiusens, if someone types a search query into the scope... nothing happens right now :P
[17:05] <sergiusens> kyrofa: not sure you noticed, but I changed installed_only to sources=[remote,local]
[17:05] <sergiusens> kyrofa: for the new api; that makes the definition of a resource look better
[17:05] <kyrofa> sergiusens, I didn't notice, but I agree
[17:06] <kyrofa> sergiusens, okay, so to answer your question: Can you define what you mean by elastic search?
[17:06] <sergiusens> kyrofa: and I am debating if PUT should change state (installed,uninstalled) and if we should get rid of DELETE
[17:06] <kyrofa> sergiusens, you mean turn PUT into a toggle?
[17:06] <sergiusens> kyrofa: the store allows you to do stuff like https://search.apps.ubuntu.com/api/v1/search?q=content:%22framework%22
[17:07] <sergiusens> kyrofa: but if the scope is just going to be a random search box (which makes it user friendly), I don't see much use of exposing that directly
[17:07] <kyrofa> sergiusens, agreed, I don't think the scope can possibly make use of that
[17:08] <sergiusens> in other words, snappy takes care of that for you
[17:08] <sergiusens> or should at least
[17:08] <kyrofa> Yeah, just knowing that I can use the q param fixes my problem
[17:08] <kyrofa> Want me to add a comment to the REST doc?
[17:14] <sergiusens> kyrofa: sure, btw, you have edit rights now too so if you want to edit or suggest feel free
[17:14] <kyrofa> sergiusens, ah good deal!
[17:36] <elopio> sergiusens: how is it possible that your tarmac catches lint errors that mine locally doesn't?
[17:36] <elopio> aren't we all getting it from github?
[17:40] <elopio> I see the errors now, it needed an update.
[17:40]  * elopio fixes lints.
[17:43] <sergiusens> elopio: heh, so two things can cause this, the merge causes lint errors (unlikely) or your lint package needs updating
[17:43] <sergiusens> tarmac installs the latest lint on every merge
[17:43] <elopio> sergiusens: it seems lint was updated recently and now it catches more errors than before. Which is nice.
[17:44] <elopio> probably we should make our run_checks smarter, so it updates golint.
[17:44] <sergiusens> elopio: yeah, I prefer tarmac always grabbing latest instead of having to manually do this every now and then
[17:44] <sergiusens> elopio: for real success just run ./.tarmac.sh
[17:45] <sergiusens> elopio: btw, do you QA approve of this https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 ?
[17:47] <sergiusens> ogra_: did you trigger a new build?
[17:48] <elopio> sergiusens: I do, yes. As far as I could see, it doesn't affect the reboots, updates, rollbacks.
[17:48] <sergiusens> elopio: ok, I'll get it into the store in a bit
[17:57] <elopio> can somebody please take a look at this? https://code.launchpad.net/~elopio/snappy/fix1468846-lint/+merge/263012
[17:57] <elopio> so we can resume landings.
[17:57] <sergiusens> sure
[17:58] <sergiusens> elopio: strange that helpers/touch.go was not errored on before though
[20:56] <ralsina> Hello! I am trying to setup snappy on kvm using https://developer.ubuntu.com/en/snappy/start/ and it seems to work, except that I can't login into the VM using ubuntu/ubuntu as it says there. Any hints/other passwords? ;-)
[21:25] <bschaefer> hello, is there a 15.10 daily image of snappy core? Or a 15.10 core image sitting around? (Been testing on 15.04 and want to move up :)
[21:29] <manik_> bschaefer: you can see the schedule for released images here- https://launchpad.net/snappy
[21:29] <manik_> bschaefer: 15.04.1 is the latest snappy core available at the moment
[21:30] <bschaefer> but there should still be a 15.10 image or from the site a rolling image
[21:30] <bschaefer> manik_, thanks!