[00:59] <Logan> does someone want to do a quick no-change rebuild of a package in main for me? pretty please? :P
[00:59] <Logan> it's to fix an FTBFS of a package that build-depends on it
[01:04] <TheMuso> Logan: Sure, whats the package?
[01:04] <Logan> :D
[01:04] <Logan> ruby-nokogiri
[01:04] <Logan> see https://launchpad.net/ubuntu/+source/ruby-fog-xml/0.1.1-5/+build/7643404
[01:04] <Logan> the Ruby 2.2 test is failing because it can't import nokogiri/nokogiri.so... because ruby-nokogiri wasn't built against Ruby 2.2
[01:05] <Logan> and the shared objects are split up by Ruby version in Rubyland
[01:05] <TheMuso> So with this no-change rebuild, do you want that other package retried once this is published?
[01:05] <Logan> you can steal this changelog entry that I used for ruby-curb: https://launchpad.net/ubuntu/+source/ruby-curb/0.8.8-1build1 :)
[01:06] <TheMuso> Thanks.
[01:06] <Logan> I can retry it since it's in universe
[01:06] <TheMuso> Oh ok.
[01:07] <Logan> we should probably have a transition tracker for this - not sure what I'd make the rule be
[01:08] <TheMuso> I don't usually involve myself in bigger transitions, but happy to take care of this since its a quick rebuild.
[01:09] <Logan> cheers :)
[01:09] <Logan> smart move ;P
[01:09] <TheMuso> heh
[01:10] <TheMuso> Just doing a quick build to make sure it does in fact build, then will upload.
[01:10] <Logan> did that locally too, but I figured you'd do it again either way :P
[01:10] <Logan> as a good core dev
[01:11] <TheMuso> Of course, it may yet fail on an arch we haven't tested it on, but I doubt it.
[01:11] <Logan> true
[01:11] <TheMuso> Logan: Ok done.
[01:11] <Logan> thanks so much!
[01:11] <TheMuso> You're welcome.
[07:16] <dholbach> good morning
[08:43] <alkisg> stgraber: for ubuntu 15.10, what's the best thing to do considering the ltsp-client-core service? We currently ship sysvinit and upstart jobs, should we also ship a systemd service file? Do we remove the upstart job? Can we keep all 3 of them for easier backporting, and have debconf select which one to install?
[10:25] <darkxst> what is this!?!? https://www.facebook.com/events/1686258078264110/ http://www.ubuntuplanet.org/
[10:27] <darkxst> can he even do that? steal trademarks, or is ubuntu itself not trademarked?
[10:30] <sil2100> pitti: ping, hey, you around on IRC? I would like to request a manual test-run of langpack-o-matic for ubuntu-rtm/15.04 :)
[10:35] <maxb>  http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy
[10:43] <sil2100> @pilot in
[10:45] <darkxst> maxb, I just emailed the links to legal, not like anyone around here is likely to know the answers really!
[11:16] <sil2100> @pilot out
[11:28] <popey> Is there a limit on how long a build can take in an (armhf) ppa? A build I started seems to have died, and I don't know why.. https://launchpadlibrarian.net/214631002/buildlog_ubuntu-wily-armhf.libreoffice-vanilla_1%3A5.0.0~rc3.1-1ubuntu1~wily4_BUILDING.txt.gz "dpkg-buildpackage died"
[11:30]  * dholbach hugs sil2100
[11:32] <cjwatson> popey: there's an inactivity limit, but that's not what happened here
[11:32] <cjwatson> popey: your build is at least partly parallelised, so the real error will be buried a bit further up (because it took some running jobs a while to finish after the error)
[11:33] <popey> ah
[11:33] <cjwatson> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[11:33] <cjwatson> Segmentation fault (core dumped)
[11:33] <cjwatson> checking for snprintf... /«PKGBUILDDIR»/external/jfreereport/ExternalProject_jfreereport_libbase.mk:20: recipe for target '/«PKGBUILDDIR»/workdir/ExternalProject/jfreereport_libbase/build' failed
[11:33] <cjwatson> make[2]: *** [/«PKGBUILDDIR»/workdir/ExternalProject/jfreereport_libbase/build] Error 139
[11:33] <cjwatson> make[2]: *** Waiting for unfinished jobs....
[11:33] <cjwatson> this is probably one that doesn't work under qemu-user-static
[11:33] <cjwatson> not very surprising for libreoffice
[11:34] <popey> bum
[11:35] <popey> is there a way I can build on real hardware (assuming that would be more successful)?
[11:35] <cjwatson> only if that PPA will never have non-Canonical uploaders
[11:35] <popey> probably not for _that_ ppa.
[11:36] <cjwatson> you can create a dedicated PPA with limited uploaders, and ask webops to make it devirtualised and add armhf
[11:36] <popey> okay, will do, thanks.
[11:36] <cjwatson> and then copy from that PPA to this one
[11:36] <popey> got it.
[11:36] <cjwatson> or you can wait for arm scalingstack to be done
[12:21]  * sil2100 hugs dholbach back
[12:21] <sil2100> @pilot in
[12:22] <dholbach> :)
[13:30] <sil2100> @pilot out
[14:42] <roaksoax> ok
[14:57] <melodie> hi
[14:59] <melodie> infinity if you are around, I would have two questions related to zram-config in Trusty 14.04.3. first question, is it normal, with the zram-config package installed in the live, once the live installed to hdd zram-config does not start and even, refuses to start? (here is a pastebin : http://pastebin.fr/40804 )
[15:00] <melodie> the second question will related to the amount of RAM available in the machine (the part in the compcache script located in /usr/share/initramfs-tools/hooks)
[15:02] <infinity> The compcache script doesn't relate at all to zram-config.
[15:02] <melodie> hi infinity
[15:02] <melodie> yes, it's part of the initramfs-tools
[15:02] <melodie> I just checked with dpkg -S
[15:02] <infinity> And 'initctl: Unknown job: zram-config' implies there's no job to start.
[15:03] <melodie> why is that? it's installed so why does it not start?
[15:04] <infinity> melodie: upstart doens't know it's installed, so something's wrong with your setup, IMO.
[15:05] <melodie> what do I need to do to investigate?
[15:05] <infinity> Well, for starters, does /etc/init/zram-config.conf exist?
[15:06] <melodie> no it doesn't
[15:06] <infinity> Well, there you go.
[15:06] <infinity> It should. :P
[15:06] <melodie> if it's in the package why didn't it land there?
[15:06] <melodie> (in the live, it does work)
[15:07] <infinity> melodie: Given that I didn't install your system, I don't know the answer to your question.
[15:07] <melodie> I see it in the "dpkg -L" output though
[15:07] <infinity> melodie: Something or something deleted it, I guess.
[15:07] <melodie> :/
[15:09] <melodie> anyway this explains why it works again once removed and installed again
[15:10] <melodie> thank you infinity
[15:10] <melodie> if you have any idea how I could investigate further, I would like to find out
[15:11] <infinity> Not really sure, given that I have no idea how you're installing things.
[15:11] <melodie> it is in a list of packages I install in a chroot before building the iso (with Ubuntu-Builder)
[15:12] <melodie> the basis used is Ubuntu Mini Remix which contains the bare minimum
[15:12] <infinity> Right, I don't know that tool at all, so I'd be debugging from scratch.
[15:13] <melodie> you helped me already, I have a start on which  dig
[15:13] <melodie> thank you very much
[15:16] <melodie> about initramfs-tools, I see it's the kernel team which is in charge, and in the file compcache there is a limitation for the amount of ram : it says "if we are in a machine where there is more than 512MB ram, then we don't start zram in the live". but when I tested Lubuntu live, in a machine with 1GB zram was active. where can I get info about how that works?
[15:18] <infinity> melodie: Like I said, that has NOTHING to do with zram-config.
[15:19] <infinity> That code should just be torn out of initramfs-tools (or replaced by zram-config) when I find the time.
[15:19] <infinity> melodie: lubuntu is using zram-config, not the initramfs-tools stuff.
[15:26] <ogra_> infinity, iirc that code was a hack to make it possible to support 256M installs ... i think our minimal reqs. were bumped since then
[15:26] <ogra_> (so yeah, just wipe it from the face of the earth)
[15:31] <melodie> hi ogra_
[15:32] <melodie> infinity I know lubuntu is using zram-config, yet initramfs-tools are probably installed there too?
[15:33] <melodie> ogra_ the comment says that "it should not be started if there is more than 512" which I find very strange
[15:33] <infinity> melodie: Yes, but just ignore that bit.  It's inconsequential.
[15:33] <infinity> melodie: The comment is commenting what the code *does*.
[15:33] <melodie> infinity ok
[15:33] <melodie> I know what comments are for :D
[15:33] <melodie> very helpful
[15:33] <infinity> melodie: It only runs compcache stuff on really low ram systems.  It's also, as ogra points out, obsolete.
[15:34] <ogra_> well, the code might be broken since :)
[15:34] <tseliot> infinity: what can I do to help get nvidia 352 in wily?
[15:34] <infinity> tseliot: Buy an AA a coffee?
[15:34] <melodie> ogra_ in the Openbox version I do, I want zram-config to work on the live and in the install
[15:34] <ogra_> melodie, then use zram-config
[15:35] <ogra_> the compcache script in initramfs-tools is completely unrelated
[15:35] <melodie> ogra_ zram-config is indeed installed in all versions
[15:35] <melodie> I didn't know it was unrelated
[15:35] <ogra_> well, fine then :)
[15:36] <tseliot> infinity: how much coffee would that be? You promised you'd do it. It's been a month now, and I'd like to be able to upload a newer release before I go on holiday :)
[15:36] <infinity> Not quite a month yet.
[15:36] <infinity> Close, though. :/
[15:36] <infinity> I'll find some time today while kernel sprinting.
[15:36] <melodie> ogra_ not fully fine because "something" makes /etc/init/zram-config.conf disappear between the live session and the install. I need to find what causes that. :/
[15:36] <infinity> I hope.
[15:37] <tseliot> infinity: thanks
[15:38] <ogra_> melodie, yeah, but thats unrelated to the compcache script for sure :)
[15:55] <melodie> ogra_ I have no idea what it is related to so I am starting to investigate. I have a vbox machine running on the tower now, and I launched the installer. I look into /var/log/installer to see what files are created there. I hope it's the right place?
[15:56] <ogra_> for live boots there is a casper log somewhere (i forgot where, its years that i looked into that last)
[16:07] <melodie> ogra_ ok
[16:47] <cjwatson> pitti,Laney: I'm confused by http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haskell-hoogle - it says test in progress for armhf, but the link is 404
[16:54] <melodie> infinity ogra_ I found where my issue was : zram-config.conf was not in the iso of the 64bits version to start with. I am now redoing the iso
[16:54] <melodie> using infinity's piece of script provided former, to not start daemons in a chroot.
[16:54] <melodie> in the 32bits version I don't have the issue
[16:55] <ogra_> but only half the bits !
[16:55] <ogra_> :)
[16:55] <melodie> where I am astonished : to fix it in an install, I tried first to reinstall it : but this didn't work
[16:55] <melodie> I first had to remove it completely and then install it anew
[16:56] <melodie> how come the simple re-install would not add the missing file?
[16:56] <melodie> ogra_ yes, half the bits for half sized bus :D
[16:58] <cjwatson> if it's a conffile, simple reinstall preserves the local change that the conffile is removed - you'd need to pass -o Dpkg::options::=--force-confmiss
[16:58] <cjwatson> (to apt-get)
[16:58] <melodie> hello cjwatson
[16:59] <melodie> just as is?
[17:00] <melodie> cjwatson and conf file yes, it bears ".conf" as a name extension, while it's really a start file (isn't it strange to have start files having for name and role "conf files" ?)
[17:00] <cjwatson> conffile is a technical term not relating to the file extension
[17:00] <cjwatson> but files in /etc that are shipped in .debs are generally conffiles
[17:00] <melodie> yes?
[17:01] <cjwatson> and yes, just as is
[17:01] <melodie> this one is specifically in /etc/init
[17:01] <cjwatson> I don't care
[17:01] <melodie> :)
[17:01] <melodie> ok
[17:02] <melodie> cjwatson thank you
[17:02] <cjwatson> np
[18:02] <cjwatson> pitti,Laney: never mind, seems to have cleared up by itself