[00:52] <cyphermox> flexiondotorg: we'll still need someone else (dholbach?) to review yuyo, but have you addressed the things I pointed out?
[00:52] <cyphermox> I'd be ready to look at another one ;)
[00:53] <flexiondotorg> cyphermox, I'm just pushing a pull-request to the upstream git repo.
[00:53] <cyphermox> oh cool.
[00:53] <cyphermox> that will make the rules file simpler
[00:53] <flexiondotorg> cyphermox, Indeed.
[01:09] <flexiondotorg> cyphermox, Yuyo pushed upstream. Contacted Sam, he has some other fixes to apply.
[01:09] <cyphermox> cool
[01:09] <flexiondotorg> So, I think next up is ubuntu-mate-artwork
[01:09] <cyphermox> great.
[01:09] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork
[02:47] <flexiondotorg> While we wait for GitHub to sync to LP, maybe the grub theme is next?
[02:48] <flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/grub2-themes-ubuntu-mate
[06:40] <pitti> Good morning
[06:58] <darkxst> pitti, hi, still no luck with systemd boot hang, invoke-rc never returns so ||true isnt helping
[07:07] <pitti> darkxst: (OTP, brb)
[07:10] <mgedmin> who maintains ubuntu-release-upgrader?  http://pad.lv/1417880 is a papercut, IMHO (easy to fix, annoying to many people)
[07:11] <pitti> darkxst: argh, invoke-rc.d is blocking? we have two patches which are supposed to avoid that, but perhaps that happens too late for them to apply
[07:11] <pitti> darkxst: incidentally that's something I'm just discussing on the upstream list..
[07:14] <pitti> darkxst: this should help: http://paste.ubuntu.com/10048858/  ; not a complete fix yet, but at least it should avoid the hang; I think it should also make the || true unnecessary
[07:16] <pitti> darkxst: followed up to the bug
[07:17] <darkxst> pitti, ok, will try it out in a bit, have to pop out to shops first
[07:17] <pitti> darkxst: thanks; this is quite a tricky problem unfortunately, so thanks for your patience
[07:30] <slangasek> xnox: hi, hadn't you at some point had a patch related to enabling i386 ovmf builds?  I don't find it in the edk2 bug report (bug #1272434) or in the Debian bts
[07:31] <slangasek> xnox: I'm updating to a new upstream commit of edk2 for arm64 support, and was hoping to spare myself the pain of going through the requisite packaging changes if you'd already done so
[07:36] <darkxst> pitti, ok it did boot now
[07:37] <pitti> darkxst: that's with --no-block?
[07:37] <darkxst> pitti, yes with you --no-block patch
[07:37] <darkxst> although I still had the || true in samba hook as well
[07:39] <pitti> darkxst: that wouldn't be necessary with the --no-block fix (I think), but with a slighly more correct fix it's still the right thing to do
[07:45] <darkxst> pitti, right, I guess a hook shouldnt cause the unit to fail
[07:45] <pitti> darkxst: it's not the unit; the problem is that a failed invoke-rc.d reload (because smbd isn't running you can't reload it) breaks DHCP
[07:46] <pitti> darkxst: as for some weird reason this is a DHCP enter hook, not an exit hook
[07:46] <pitti> and if the enter hook fails, the actual DHCP isn't done
[08:11] <darkxst> pitti, I guess samba needs to export a dhcp server over netbios or something?
[08:11] <pitti> darkxst: yeah, perhaps; for now I assume that it being an enter hook is intended
[08:13] <dholbach> good morning
[08:18] <pitti> darkxst: I looked at this again, and I think the || true was a red herring; I thought I had DHCP failing on a hook that exits 1 yesterday, but I can't reproduce this
[08:18] <pitti> darkxst: so dropping the || true should be fine
[08:18]  * pitti finds debian bug 652942 which is the same issue
[08:45] <Noskcaj> Can someone please look at bug 1417253
[08:53] <pitti> dpm: ah, thanks for the l10n-stats heads-up!
[08:53] <pitti> dpm: once it's all there, I'll adjust langpack-o-matic accordingly
[08:53] <dpm> pitti, yw. ack, sounds great!
[09:54] <Saviq> doko_, hey, not sure if it matters, but I was unable to reproduce the gcc failure locally (except once when it rebooted my phone)
[09:54] <Saviq> doko_, which is why I did not submit any preprocessed source, was hoping you could get that from a builder
[09:55] <cjwatson> Saviq: We can't extract anything from builders.
[09:56] <cjwatson> Saviq: Have you tried on porter-armhf?
[09:56] <pitti> well, you could abuse the build log by cat'ing stuff
[09:56] <cjwatson> Sure
[09:56] <cjwatson> But it's probably easier to reproduce on a porter box
[09:56] <pitti> (not nice if the stuff you are cat'ing is large, though)
[09:57] <Saviq> cjwatson, not sure what porter-armhf is
[09:57] <pitti> *nod*, just mentioning the last resort; I've had some cases where stuff wasn't reproducible on porter boxes
[09:57] <cjwatson> You don't know about porter boxes? *blink*
[09:57] <cjwatson> https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes
[09:57]  * cjwatson upgrades the relevant chroot
[09:58] <pitti> I wish they had a sensible schroot setup, but otherwise they are great indeed
[09:59] <cjwatson> Yeah, I have an RT in for that
[09:59] <cjwatson> One of these days
[09:59]  * Saviq pubkey-denied :/
[10:00] <cjwatson> Ask IS to add you to the porting_team group.  All technical staff in UE should be in that AFAIK ...
[10:06] <xnox> slangasek: i have some refactoring done to support alt builds.
[10:06] <xnox> slangasek: however, efi-shell does not have gcc assembly files ported to compile for ia32 with gcc compiler (MSVC only compiler)
[10:07] <xnox> and i got disappoint.
[10:10] <slangasek> Saviq: separately, you should be aware that doko is already working on using the hand-cranked armhf porter box to try to debug your recent gcc ICE so throwing more logins at the problem is unlikely to resolve it more quickly
[10:11] <Saviq> slangasek, understood, he did put the bug in Incomplete and asked for preprocessed sources, so wasn't sure whose court the ball was in
[10:11] <slangasek> Saviq: ah - actually the machine is currently idle, so we can try to get a reproducer on there.  however it is a panda
[10:12] <Saviq> slangasek, I'll try again on my phone here, prolly faster than a panda
[10:12] <slangasek> ok
[10:13] <Saviq> I *think* when I tried before I might not have been using the new gcc, only realized today the silo PPAs have proposed enabled
[10:14] <cjwatson> Saviq: the new gcc is in the release pocket anyway
[10:15] <slangasek> correct
[10:17] <Saviq> cjwatson, yeah, I know, just saying that might be why I wasn't able to repro locally yesterday
[10:18] <cjwatson> slangasek: really?  the relevant chroot in the porter box doesn't have anything like unity8's build-deps installed - I'm putting those in place at the moment
[10:19] <slangasek> cjwatson: right, perhaps he didn't actually get past the point of complaining to me that shedir was still the porter box ;P
[10:35]  * cjwatson tries a build on shedir, since apparently nobody else is
[10:57] <cjwatson> doko,Saviq,slangasek: bug updated with the usual stuff from README.Bugs
[10:57] <Saviq> cjwatson, thanks
[12:22] <caribou> tkamppeter: do you have time to sponsor a fix I have for CUPS : bug #1352809
[12:22] <caribou> or anyone who feels like uploading cups
[12:38] <pitti> darkxst: still here by chance?
[12:41] <tkamppeter> caribou, no problem, I can do it.
[12:42] <caribou> tkamppeter: I extracted & adapted only the fix for the CUPS_SERVER override. Details are in the comments with reference to the upstream bug
[12:48] <tkamppeter> caribou, OK, fix is simple will add it to current Debian and Vivid, via Debian GIT repo.
[12:49] <caribou> tkamppeter: ah good; I intended to do a reportbug on it (didn't know you were on the debian side)
[12:55] <caribou> tkamppeter: thanks. Once it gets in vivid I'll SRU to trusty & Utopic
[12:58] <slangasek> xnox: can you send me a pointer to whatever your refactoring was to support alt builds?  I need to reconcile it with dannf's requests for arm64 support
[12:59] <xnox> slangasek: ok.
[12:59] <xnox> slangasek: not asap.
[12:59] <slangasek> ok
[13:00] <slangasek> xnox: I'll hold off on uploading until I can take a look at your proposal; I don't want to reorganize this stuff in the archive more than once
[13:02] <slangasek> Saviq: added a suggestion of a possible unity8 temporary workaround to the bug report fyi
[13:02] <Saviq> slangasek, thanks
[13:03] <Saviq> will test in a moment
[13:14] <Saviq> slangasek, this seems to get us through indeed, thanks a bunch
[13:14]  * Saviq runs to prep an MP
[14:33] <loin> hi, is there a easy way to build a executable on a newer ubuntu that will run on older debians? currently it says that my glibc is too old when trying to run on older systems. when i objdump i find out that it uses memcpy from GLIBC_2.14 instead of using the memcpy from an older version. i don't want to use hacks such as __asm__(".symver memcpymemcpy@GLIBC_2.2.5"); in my c code
[14:34] <mgedmin> loin, pbuilder or sbuilder can be helpful there, AFAIU
[14:36] <loin> mgedmin: is this even worth bothering with? should i just install a older ubuntu and have the older glibc natively?
[14:37] <mgedmin> these tools create a chroot with a minimal older ubuntu/debian installation that you can use to build binaries compatible with those versions
[14:37] <rbasak> loin: build it on a much older release maybe? I would use sbuild - it's much easier than installing an older Ubuntu, quicker once set up and easily repeatable for easier developer iteration.
[14:37] <mgedmin> and you can have many chroots for many versions
[14:52] <cjwatson> loin: I agree with mgedmin and rbasak.  https://wiki.ubuntu.com/SimpleSbuild
[14:53] <loin> thanks cjwatson, i'm still investigating
[14:55] <cjwatson> in general new libc is compatible with binaries built against old libc but not necessarily vice versa.  hacking around with symver is a recipe for weird failures and horrible confusion.
[14:56] <loin> cjwatson: that's why i'm not doing it
[14:56] <loin> wish there was a simpler way, though
[14:57] <cjwatson> sbuild is really easy once you absorb the capital cost of setting it up.
[14:57] <rbasak> mk-sbuild helps with that. Although I feel it could be improved by requiring less stuff, it isn't too bad.
[14:58] <cjwatson> and if you aren't doing things that are in the form of source packages, then setting up sbuild involves setting up schroot instances for the relevant releases, which you can use in isolation
[14:58] <pitti> https://wiki.ubuntu.com/SimpleSbuild FTR
[14:58] <cjwatson> linked above :)
[14:59] <pitti> ah sorry, missed that
[15:03] <loin> thanks guys, this has been helpful
[15:15] <mterry> @pilot in
[15:20] <rbasak> I'll soon be uploading a new src:mysql-5.6 that takes over some binary packages (eg. mysql-common) from src:mysql-5.5.
[15:21] <rbasak> Is there anything special I need to do for this? For example, do I need to upload a new src:mysql-5.5 that drops mysql-common? Or will the new one just take over?
[15:21] <pitti> rbasak: the new one will take over
[15:21] <rbasak> OK, thanks!
[15:21] <pitti> rbasak: i. e. if multiple sources build a binary foo, the one with the highest version number wins
[15:21] <pitti> rbasak: that said, we should still clean up the old sources of course
[15:22] <pitti> but nothing bad should happen
[15:22] <rbasak> That makes sense. Yeah - the old src:mysql-5.5 will need to be deleted afterwards.
[15:24] <cjwatson> yeah, we should clean up the old one not least because it will be impossible to reupload it without removing those binaries
[15:33] <flexiondotorg_> Hi
[15:34] <flexiondotorg_> cyphermox, Thanks for everything yesterday.
[15:34] <flexiondotorg_> I'm going to try and clean up some more packages.
[15:34] <flexiondotorg_> cyphermox, When you have the time let me know and I'll suggest the next package for assessment 😃
[15:35] <cyphermox> flexiondotorg_: it will take me a bit
[15:35] <cyphermox> but if you have time to bug dholbach for the second review you need that could work in the meantime ;)
[15:35] <flexiondotorg_> No problem. I leanrt enough yesterday to hopefully make some corrections myself.
[15:35] <flexiondotorg_> dholbach, How are you fixed today?
[15:36] <Unit193> cyphermox: Anything new for NM?  Chance of it in vivid?
[15:36] <flexiondotorg_> dholbach, Do you have time to look at some packages that will need uploading into the official archive?
[15:36] <dholbach> no, not today I'm afraid
[15:36] <flexiondotorg_> dholbach, OK.
[15:37] <dholbach> if you want, you can subscribe me to the bug or MP and I can take a look at it tomorrow if nobody beats me to it
[15:37] <cyphermox> Unit193: NM 0.9.10.0 is in vivid barring one bug if you paired a bluetooth phone and installed the ubutnu-desktop-next metapackage,
[15:38] <Unit193> cyphermox: Great!  I presume you saw 1.0.0 hit exp?
[15:38] <cyphermox> dholbach: thanks, we can ask any other MOTU too, it's for landing new packages
[15:38] <cyphermox> Unit193: yes
[15:38] <dholbach> brilliant, thanks
[15:38] <cyphermox> Unit193: just have no time just now to prepare it, and it would take time to update the patches, do the testing for everything, etc.
[15:38] <cyphermox> maybe off hours, later this week? :)
[15:39] <Unit193> Yes, understandable.  .10 is the one I'm looking forward to.
[15:39] <cyphermox> it's already landed, you can feel free to play with it ;)
[17:11] <arges> infinity: any objections/issues with sru-releasing all the xserver/xorg stuff?
[17:16] <dobey> the lts-utopic xorg?
[17:27] <dupingping> how can i get full window image includes it's decoration in opengl plugin and convert it to memory buffer?
[17:53] <pitti> darkxst: ok, afer pulling out my hair for another day, I now followed up to bug 1417010 again; I'd be grateful if you could test this again
[18:24] <mterry_> @pilot out
[18:25] <mterry> @pilot out
[18:51] <cyphermox> xnox: hey, would you happen to have time for a code-review for ubiquity?
[19:01] <smoser> infinity, http://paste.ubuntu.com/10058049/
[19:01] <smoser> does that make sense?
[19:01] <smoser> 2 of the cells have no memory.
[19:02] <smoser> (seeing this because openstack gets a 'None' for memory and tries to divide it)
[19:19] <system0x01>  I consider squash some of the bugs. Which tool/tools will be appropriate  for that purpose
[19:26] <cyphermox> system0x01: I suggest you start by reading http://packaging.ubuntu.com/html/introduction-to-ubuntu-development.html; section 2 will tell you all you need to know about the tools suggested
[20:47] <darkxst> pitti, updated "service" script boots fine
[21:41] <flexiondotorg_> Trevinho, Are you available for a quick question?
[22:32] <bdmurray> pitti: https://code.launchpad.net/~brian-murray/apport/bug-1084979/+merge/248685
[22:32] <bdmurray> pitti: Could you have a look at that during your work day?
[23:38] <sarnold> "Does Ubuntu have some piuparts facility somewhere that can be integrated with PPA so new builds would be automatically tested for install/upgrade/remove?" https://bugs.launchpad.net/bugs/1417917