[00:52] flexiondotorg: we'll still need someone else (dholbach?) to review yuyo, but have you addressed the things I pointed out? [00:52] I'd be ready to look at another one ;) [00:53] cyphermox, I'm just pushing a pull-request to the upstream git repo. [00:53] oh cool. [00:53] that will make the rules file simpler [00:53] cyphermox, Indeed. [01:09] cyphermox, Yuyo pushed upstream. Contacted Sam, he has some other fixes to apply. [01:09] cool [01:09] So, I think next up is ubuntu-mate-artwork [01:09] great. [01:09] https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/ubuntu-mate-artwork [02:47] While we wait for GitHub to sync to LP, maybe the grub theme is next? [02:48] https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-mate/grub2-themes-ubuntu-mate === zerick_ is now known as zerick [06:40] Good morning [06:58] pitti, hi, still no luck with systemd boot hang, invoke-rc never returns so ||true isnt helping [07:07] darkxst: (OTP, brb) [07:10] who maintains ubuntu-release-upgrader? http://pad.lv/1417880 is a papercut, IMHO (easy to fix, annoying to many people) [07:10] Launchpad bug 1417880 in ubuntu-release-upgrader (Ubuntu) "Invisible prompts in do-release-upgrade" [Undecided,New] [07:11] 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] darkxst: incidentally that's something I'm just discussing on the upstream list.. [07:14] 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] darkxst: followed up to the bug [07:17] pitti, ok, will try it out in a bit, have to pop out to shops first [07:17] darkxst: thanks; this is quite a tricky problem unfortunately, so thanks for your patience [07:30] 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:30] bug 1272434 in edk2 (Ubuntu) "Please provide i386 & arm64 builds" [Wishlist,Confirmed] https://launchpad.net/bugs/1272434 [07:31] 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] pitti, ok it did boot now [07:37] darkxst: that's with --no-block? [07:37] pitti, yes with you --no-block patch [07:37] although I still had the || true in samba hook as well [07:39] 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] pitti, right, I guess a hook shouldnt cause the unit to fail [07:45] 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] darkxst: as for some weird reason this is a DHCP enter hook, not an exit hook [07:46] and if the enter hook fails, the actual DHCP isn't done [08:11] pitti, I guess samba needs to export a dhcp server over netbios or something? [08:11] darkxst: yeah, perhaps; for now I assume that it being an enter hook is intended [08:13] good morning [08:18] 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] darkxst: so dropping the || true should be fine [08:18] * pitti finds debian bug 652942 which is the same issue [08:19] Debian bug 652942 in samba-common "dhcp hook runs reload on shutdown (after service has been stopped)" [Important,Open] http://bugs.debian.org/652942 [08:45] Can someone please look at bug 1417253 [08:45] bug 1417253 in rt-extension-assettracker (Ubuntu) "[RM] Please remove rt-extension-assettracker from the archive" [Undecided,New] https://launchpad.net/bugs/1417253 [08:53] dpm: ah, thanks for the l10n-stats heads-up! [08:53] dpm: once it's all there, I'll adjust langpack-o-matic accordingly [08:53] pitti, yw. ack, sounds great! [09:54] 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] doko_, which is why I did not submit any preprocessed source, was hoping you could get that from a builder [09:55] Saviq: We can't extract anything from builders. [09:56] Saviq: Have you tried on porter-armhf? [09:56] well, you could abuse the build log by cat'ing stuff [09:56] Sure [09:56] But it's probably easier to reproduce on a porter box [09:56] (not nice if the stuff you are cat'ing is large, though) [09:57] cjwatson, not sure what porter-armhf is [09:57] *nod*, just mentioning the last resort; I've had some cases where stuff wasn't reproducible on porter boxes [09:57] You don't know about porter boxes? *blink* [09:57] https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes [09:57] * cjwatson upgrades the relevant chroot [09:58] I wish they had a sensible schroot setup, but otherwise they are great indeed [09:59] Yeah, I have an RT in for that [09:59] One of these days [09:59] * Saviq pubkey-denied :/ [10:00] Ask IS to add you to the porting_team group. All technical staff in UE should be in that AFAIK ... [10:06] slangasek: i have some refactoring done to support alt builds. [10:06] slangasek: however, efi-shell does not have gcc assembly files ported to compile for ia32 with gcc compiler (MSVC only compiler) [10:07] and i got disappoint. [10:10] 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] 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] 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] slangasek, I'll try again on my phone here, prolly faster than a panda [10:12] ok [10:13] 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] Saviq: the new gcc is in the release pocket anyway [10:15] correct [10:17] cjwatson, yeah, I know, just saying that might be why I wasn't able to repro locally yesterday [10:18] 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] 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 === _salem is now known as salem_ [10:57] doko,Saviq,slangasek: bug updated with the usual stuff from README.Bugs [10:57] cjwatson, thanks === marcusto_ is now known as marcustomlinson_ === mnepton is now known as mneptok === Cimi_ is now known as Cimi [12:22] tkamppeter: do you have time to sponsor a fix I have for CUPS : bug #1352809 [12:22] bug 1352809 in cups (Ubuntu) "/usr/bin/lp on Trusty using -h option doesn't work as expected" [Medium,In progress] https://launchpad.net/bugs/1352809 [12:22] or anyone who feels like uploading cups === MacSlow is now known as MacSlow|lunch === doko_ is now known as doko === marcustomlinson_ is now known as marcustomlinson [12:38] darkxst: still here by chance? [12:41] caribou, no problem, I can do it. [12:42] 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] caribou, OK, fix is simple will add it to current Debian and Vivid, via Debian GIT repo. === Quintasan_ is now known as Quintasan [12:49] tkamppeter: ah good; I intended to do a reportbug on it (didn't know you were on the debian side) [12:55] tkamppeter: thanks. Once it gets in vivid I'll SRU to trusty & Utopic [12:58] 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] slangasek: ok. [12:59] slangasek: not asap. [12:59] ok [13:00] 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] Saviq: added a suggestion of a possible unity8 temporary workaround to the bug report fyi [13:02] slangasek, thanks [13:03] will test in a moment [13:14] slangasek, this seems to get us through indeed, thanks a bunch [13:14] * Saviq runs to prep an MP === Malsasa_ is now known as Malsasa === pgraner-afk is now known as pgraner === Neo31` is now known as Neo31 === MacSlow|lunch is now known as MacSlow === darkbasic_ is now known as darkbasic [14:33] 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] loin, pbuilder or sbuilder can be helpful there, AFAIU === Malsasa_ is now known as Malsasa [14:36] mgedmin: is this even worth bothering with? should i just install a older ubuntu and have the older glibc natively? [14:37] 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] 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] and you can have many chroots for many versions === Guest17528 is now known as rcj === rcj is now known as Guest81467 [14:52] loin: I agree with mgedmin and rbasak. https://wiki.ubuntu.com/SimpleSbuild [14:53] thanks cjwatson, i'm still investigating [14:55] 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] cjwatson: that's why i'm not doing it [14:56] wish there was a simpler way, though [14:57] sbuild is really easy once you absorb the capital cost of setting it up. [14:57] mk-sbuild helps with that. Although I feel it could be improved by requiring less stuff, it isn't too bad. [14:58] 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] https://wiki.ubuntu.com/SimpleSbuild FTR [14:58] linked above :) [14:59] ah sorry, missed that [15:03] thanks guys, this has been helpful === zumbi_ is now known as zumbi [15:15] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry [15:20] 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] 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] rbasak: the new one will take over [15:21] OK, thanks! [15:21] rbasak: i. e. if multiple sources build a binary foo, the one with the highest version number wins [15:21] rbasak: that said, we should still clean up the old sources of course [15:22] but nothing bad should happen [15:22] That makes sense. Yeah - the old src:mysql-5.5 will need to be deleted afterwards. [15:24] yeah, we should clean up the old one not least because it will be impossible to reupload it without removing those binaries === tyhicks` is now known as tyhicks === smoser` is now known as smoser [15:33] Hi [15:34] cyphermox, Thanks for everything yesterday. [15:34] I'm going to try and clean up some more packages. [15:34] cyphermox, When you have the time let me know and I'll suggest the next package for assessment 😃 [15:35] flexiondotorg_: it will take me a bit [15:35] but if you have time to bug dholbach for the second review you need that could work in the meantime ;) [15:35] No problem. I leanrt enough yesterday to hopefully make some corrections myself. [15:35] dholbach, How are you fixed today? [15:36] cyphermox: Anything new for NM? Chance of it in vivid? [15:36] dholbach, Do you have time to look at some packages that will need uploading into the official archive? [15:36] no, not today I'm afraid [15:36] dholbach, OK. [15:37] 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] 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] cyphermox: Great! I presume you saw 1.0.0 hit exp? [15:38] dholbach: thanks, we can ask any other MOTU too, it's for landing new packages [15:38] Unit193: yes [15:38] brilliant, thanks [15:38] 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] maybe off hours, later this week? :) [15:39] Yes, understandable. .10 is the one I'm looking forward to. [15:39] it's already landed, you can feel free to play with it ;) [17:11] infinity: any objections/issues with sru-releasing all the xserver/xorg stuff? [17:16] the lts-utopic xorg? [17:27] how can i get full window image includes it's decoration in opengl plugin and convert it to memory buffer? === Neo31 is now known as tester31 === tester31 is now known as Neo31 [17:53] 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 [17:53] bug 1417010 in systemd (Ubuntu) "Reloading services can result in a deadlock under systemd" [High,In progress] https://launchpad.net/bugs/1417010 [18:24] @pilot out === mterry_ is now known as mterry [18:25] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [18:51] xnox: hey, would you happen to have time for a code-review for ubiquity? [19:01] infinity, http://paste.ubuntu.com/10058049/ [19:01] does that make sense? [19:01] 2 of the cells have no memory. [19:02] (seeing this because openstack gets a 'None' for memory and tries to divide it) [19:19] I consider squash some of the bugs. Which tool/tools will be appropriate for that purpose [19:26] 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 === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [20:47] pitti, updated "service" script boots fine [21:41] Trevinho, Are you available for a quick question? [22:32] pitti: https://code.launchpad.net/~brian-murray/apport/bug-1084979/+merge/248685 [22:32] pitti: Could you have a look at that during your work day? [23:38] "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 [23:38] Launchpad bug 1417917 in mariadb-5.5 (Ubuntu) "package mariadb-server-5.5 install returned error exit status 1 due bug in mysql flags removal" [Undecided,Confirmed] === salem_ is now known as _salem