[00:08] mwhudson: no one is safe to pretend about cdbs :P [00:12] luckily i'm just adding a patch [00:15] Pharaoh_Atem: up to the j* packages with dropping php5 references :) [00:15] nacc: *\o/* [00:15] what would be the use of a delta like this? https://patches.ubuntu.com/m/mairix/mairix_0.23+git20131125-0.4ubuntu1.patch [00:16] language-pack-en-base seems to be something totally different than locales-all ? (granted, I've no clue why locales-all is needed in this package for) [00:17] Logan: --^ ? :) [00:19] mapreri: iiuc, it's so that locales get generated (and the langpacks do that too) [00:19] mapreri: and older ubuntu didn't package locales-all [00:19] mapreri: it is in xenial, though, so maybe that delta can be dropped now, not sure [00:30] slangasek: done for the day again with debdiffs, will hopefully get more done tomorrow [00:30] slangasek: three of the packages can be just rebuilt, i figured i'll just update the file in that bug at the end, if that's ok with you? [00:30] nacc: yep, that's fine, thanks! [00:30] slangasek: also, i'm going to confer with kirkland about drupal7 tmrw to make sure he's ok with its removal [00:31] slangasek: thank you for your help! [00:39] doko: do you understand the build failure for comet-ms? it gives errors about undefined references in /usr/lib/libmstoolkitlite.so to gzip functions, but 'ldd -d -r' shows it's properly linked to libz [00:58] nacc: it's weird as that change was done for xenial explicitly. [00:58] (sorry missed the highlight before...) [01:09] mapreri: i'm really not sure, oddly, loooking at the glibc changelog (http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.23-0ubuntu2/changelog), 2.21-0ubuntu1 explicitly disables locales-all [01:09] anyone want to make ibm happy and sponsor https://bugs.launchpad.net/ubuntu/+source/golang-1.6/+bug/1561271 ? :) [01:09] Launchpad bug 1561271 in golang-1.6 (Ubuntu) "updated s390x port" [Undecided,New] [01:10] mapreri: there's no mention of it being dropped from the delta, though [01:10] booh [01:10] mapreri: oh actually it's there [01:10] sorry it's a hard chagnelog to read [01:10] Merge locales back into glibc and provide locales-all (LP: #1394929) [01:11] Launchpad bug 1394929 in langpack-locales (Ubuntu) "[FFe]Please provide 'locales-all' as in Debian" [Undecided,Confirmed] https://launchpad.net/bugs/1394929 [01:11] mapreri: that only got commited on 3/16 [01:11] mapreri: so i'm guessing Logan's change predates it [01:11] and can be dropped [01:11] ok, I see [01:11] though I've never noticed locales-all was missing from ubuntu [01:12] anyway, that package is basically unmaintained in the debian, so the next force sync will have to wait [01:12] i hope whoever will do it will notice that this can be dropped. [01:17] mapreri: rmadison indicates it doesn't exist anywhere else than xenial, and that's because we generate them all with langpacks, afaict [01:33] slangasek: i did hit a weird issue with freedombox-setup; i can't run autopkgtests against it (nor against the version in the archive) if I build the pkg due to avahi failures ... might be a known problem? [01:34] nacc: nothing I know about [01:35] slangasek: ok, i'll be interested to see if the same failure is seen by autopkgtest then, and i'll try and debug it a bit tmrw otherwise [01:54] nacc: got a log? === funkyHat_ is now known as funkyHat === juliank_ is now known as juliank === Spads_ is now known as Spads [04:22] mapreri: nacc is correct [04:23] locales-all didn't exist at the time [04:23] I'll drop the delta when Debian releases a new version [04:23] no real use of switching it back to locales-all right now [05:58] good morning [06:07] Somebody around that is willing to sponsor SRU for bug 1547431? [06:07] bug 1547431 in apt-cacher-ng (Ubuntu Trusty) "Does not allow appstream files" [Medium,Confirmed] https://launchpad.net/bugs/1547431 [06:57] Good morning [06:59] doko: add a second --trigger src/ver for the additional source that should come from -proposed, or use --all-proposed to completely disable the apt pinning [07:19] good morning :) [07:35] that might sound silly, but I'm missing an upload, yesterday at 14:51 CET jamespages uploaded dpdk 2.2.0-0ubuntu6 for me [07:35] it doesn't show up in update_excuses, nor is it gone through [07:35] are there other places to watch where/if it might have failed - or are there other things currently stalled due to e.g. archive changes and such? [07:54] good morning [08:17] cpaelzer, Morning. I think there is a beta freeze around [08:25] smb: thanks, that makes sense and would explain the situation [08:25] maybe I should just call it easter weekend earlier today and check for them early next week [08:30] anyone seeing dnsmasq process running like crazy this morning ? [08:33] nevermind, own network mixup [08:34] caribou: not more than usually when it messes with my vpn [08:34] cpaelzer: :) [08:42] pitti, morning, can I please ask you to recycle the two regressions seen in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scope-click - and about that - the failure seems to be locale related, is there a guideline on what wrt locale can be expected in the adt runners? [08:46] Saviq: I retreid them [08:46] Saviq: normally C.UTF-8 [08:46] Saviq: the recent switch to glibc 2.23 might have broken something there, though [08:46] sorry, /me is sick, will crawl back to bed [08:47] pitti, oh sorry, of course, get well === king-afk is now known as cking [10:06] infinity: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/798414 -> any chance we get >250MB /boot on systems with large enough disks? [10:06] Launchpad bug 798414 in initramfs-tools (Ubuntu) "update-initramfs should produce a more helpful error when there isn't enough free space" [Medium,Confirmed] [10:30] Hi. Was the ddebs.ubuntu.com signing key change reverted? I see a file from 2008 again when I access that host. [10:31] Since around yesterday 4:15 Pacific TIme. [10:40] doko: not yet, sorry. My priority is some Juju stuff right now. I'll get to squid after this. [10:54] pkern: There was a data loss incident and ddebs had to be restored from backups, I believe [10:55] pkern: I have write access but don't want to touch it without talking to pitti, who's currently unwell [10:55] (Not least because the data loss incident was apparently somehow triggered by the attempted re-signing - don't know the details) [11:20] cjwatson: I see, thanks. Will the new signing key come back? === _salem is now known as salem_ [11:26] pkern: I'll have to defer that to pitti. [12:53] pkern: yes, and I can't re-apply the new signatures until I figured out what wiped out ddebs.u.c. [12:53] but I'm afraid I'm currently not really in a condition to do in-depth debugging [12:54] * Laney hugs pitti [12:54] get better! [12:54] thanks [12:54] just in time for the long weekend eh [13:03] * dholbach hugs pitti too [13:35] xnox, will you have some time to tackle bug #1552914 ? [13:35] bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,Confirmed] https://launchpad.net/bugs/1552914 [13:41] cyphermox, Potentially some good news. [13:41] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689 [13:41] Launchpad bug 1359689 in linux (Ubuntu Vivid) "cryptsetup password prompt not shown" [Critical,Triaged] [13:41] See my last comment. [13:41] mmkay [13:41] I'll look later... [13:41] I think I just finally saw what was wrong with keyboards [13:41] Just tested on three machines, all with different GPUs. [13:41] And had no problems. [13:41] took me long 'nough [13:42] The computers used had previously exhibited the issue. [13:43] cyphermox, Keyboards? [13:44] language selection is messed up [13:45] I saw Lubuntu has an issue. [13:45] I'll double check Ubuntu MATE. [13:46] flexiondotorg: a good test is SV [13:48] OK [13:50] cyphermox, Will this result in a respin? [13:53] I don't know, ask on #ubuntu-release [13:54] cjwatson: i noticed that secureboot-db isn't ending up in the pool for mythbuntu ISO's even though grub-efi-amd64-signed and grub-efi-amd64 are. consequently EFI installation fails. any pointers for checking why this is happening? [13:57] cyphermox, Ubuntu MATE is not affected. Swedish keyboard layout persists after install in the settings and is mapped correctly as best as I can tell. [13:58] oh, it is affected; you need to use english at the boot splash and then choose swedish [13:59] that is, unless of course someone fixed things in between yesterday's image and today's, if you're using a new image [13:59] nacc, please could you have a look at http://people.canonical.com/~ubuntu-archive/nbs.html, and removing the references for the obsolete binary packages? [14:03] superm1: I imagine recommends are disabled somewhere relevant [14:05] cjwatson: okay thanks i'll poke around looking for something related to recommends [14:05] superm1: ah, no [14:05] doko: yes, will get that done today [14:05] superm1: it's already in the livefs isn't it? [14:06] hmm, maybe not [14:06] lathiat_: i'll try and rerun this morning and paste it here [14:06] germinate thinks it should be, the manifest says it isn't [14:07] there were a few other odd ones i noticed dropped off the manifest running germinate last time (acpi-support and two or three others) [14:07] so maybe related [14:08] English was the default language, I changed the keyboard only to Swedish during the install. [14:09] superm1: ah I see [14:10] superm1: http://bazaar.launchpad.net/~mythbuntu-dev/ubuntu-seeds/mythbuntu.xenial/revision/1267 should fix it [14:11] cjwatson: ah great thanks [14:11] i'll regenerate and try [14:11] the lack of that meant that germinate considered the stuff in live-common to be installed when expanding stuff in live and above, but it wasn't actually in the task so livecd-rootfs didn't install it [14:11] superm1: don't do it immediately, it'll take a couple of xenial publisher runs to take effect [14:11] OK [14:30] stgraber: got a sec? We've got a few touch packages that want to land in xenial but are in UNAPPROVED [14:54] flexiondotorg: I'll pick the mate image to do any further testing on this [15:04] infinity: http://apple.stackexchange.com/questions/135967/can-i-use-non-apple-headphones-with-an-iphone/135972 [15:04] those bastards. [15:06] doko: ^ above: we've got a few touch packages that want to land in xenial but are in UNAPPROVED, do you have a moment to go through them === francisco is now known as Guest26205 [15:20] doko, infinity, LocutusOfBorg: I've confirmed the problem with installing fpc 3 on powerpc is related to glibc 2.23. After downgrading libc6*, gcc* and locales, fp-compiler installs just fine. Any ideas? === henrix_ is now known as henrix [15:40] arges I'll verify lp 1315755 now [15:40] Launchpad bug 1315755 in initramfs-tools (Ubuntu Trusty) "/init: line 327: egrep: not found" [High,Fix committed] https://launchpad.net/bugs/1315755 [15:40] or at least look into it [15:51] k [16:00] slangasek: so after talking to kirkland, there is interest in keeping drupal7 in the arhcive; but based upon upstream feedback, not yet present upstream even. Do you hve any guidance on the best way to proceed? I can backport the upstream fixes (once present) to our version, probably? [16:00] nacc: "interest in keeping it in the archive" doesn't make it releasable [16:00] slangasek: or, i should say, he vetoed my suggestion of dropping it :) [16:02] kirkland: so what are you expecting here? There was agreement with the server team that anything that php5 would be dropped from the archive for 16.04, in exchange for php7.0; drupal doesn't support php7. Are you asking to keep php5 in the archive now? [16:03] slangasek: i'm going to see what our drupal7 version looks like, test-wise, with php7 right now [16:23] cjwatson, slangasek: continuing my pokes of archive members :) If anyone has time to go through xenial UNAPPROVED, there are some touch packages we landed in a big u8 silo that we'd like to shepherd through [16:24] not me sorry [16:30] slangasek: Saw your im-config bug. Has whiptail replace dialog in Debian too? (im-config is a Debian package, i.e. would it need to be an Ubuntu delta? [16:30] arges verified.. no errors in kern.log or syslog. so I think that's sufficient to call it verified. lp 1315755 [16:30] Launchpad bug 1315755 in initramfs-tools (Ubuntu Trusty) "/init: line 327: egrep: not found" [High,Fix committed] https://launchpad.net/bugs/1315755 [16:34] chiluk: mark it down dude [16:34] huh? [16:34] arges what do you mean by that. [16:34] chiluk: you did, I meant put 'verification-done' in the bug [16:35] it is. [16:35] ok [16:38] mterry: Stuff will be let out en masse later today when I'm happy with thawing the beta freeze. [16:38] mterry: Unless one can make a valid argument for "IT MUST LAND IN THE NEXT TWO HOURS OR WE'LL ALL BE SET ON FIRE". [16:39] infinity: no. I was just being a bit antzy because it's annoying for our u8 devs on xenial. But not that annoying :) [16:39] infinity: thanks [16:42] infinity, one thing to note: not sure how much we messed up by deleting packages from a PPA when they were in UNAPPROVED - if you find that stuff is missing in ppa:ci-train-ppa-service/landing-013, it's now in ppa:ci-train-ppa-service/landing-057 - not sure if the new copies overwrote the previous ones [16:42] and thanks :) === nacc_ is now known as nacc [16:44] slangasek: hrm, interesting -- not necessarily an authoritative test, but i was able to configure a blog using my rebuilt drupal7, now i'm going to see if i can run the tests manually [16:45] chiluk: For which SRU are you awaiting a release? [16:45] Saviq: As in, there are two copies in the queue, and I want the -057 ones? [16:45] bdmurray: https://bugs.launchpad.net/ubuntu/trusty/+source/coreutils/+bug/1535349 [16:45] Launchpad bug 1535349 in initramfs-tools (Ubuntu Trusty) "`df /dev/sda1` no longer reports information for /dev/sda1" [Medium,Fix released] [16:46] bdmurray initramfs-tools just needs to be promoted to -updates [16:47] chiluk: and you and pitti talked about the test failures being false positives yesterday? [16:48] chiluk: oh, somebody beat me to it [16:49] bdmurray yeah.. I opened bugs against autotest yesterday about them. [16:53] Saviq, that boost bug, yes, will fix next week. Away on holiday now and dealing only with urgent things. let me assign it tomyself unless it is really urgetn [16:53] it is assigned === ochosi_ is now known as ochosi [17:03] infinity, afaict, yes, because the -013 ones were deleted from the PPA [17:04] Saviq: Kay. [17:08] slangasek: I understand from nacc that upstream drupal and upstream php are jointly working right now to get drupal7 working with php7 [17:08] slangasek: I advised nacc that we could proceed with dropping php5, AS LONG AS we're working hard to getting drupal7 to work with php7, meaning we'll probably need a drupal7 upload(s) and/or SRUs [17:09] slangasek: I'm not okay with purging drupal entirely from the archive; that would be a real disappointment to downstream Ubuntu server users [17:11] can somebody review snapcraft in the queue (important bug fix), it's not seeded anywhere [17:13] oh maybe it was just accepted [17:13] unseeded stuff is usually auto-accepted [17:13] (and this was AFAICS) [17:16] kirkland: well, it's just upstream drupal, to be clear [17:16] kirkland: php doesn't care about the sites that haven't migrated yet :) [17:16] s/sites/projects/ [17:17] nacc: hrm, really? okay, well you have contact with php, too, right? can you ask them to help? [17:17] kirkland: i seriously doubt they will [17:17] kirkland: php (language) developers don't seem to interact much with their downstream, afaict [17:17] kirkland: ok - I am also comfortable with pulling php5 out from under drupal7 and SRUing drupal7 fixes in if necessary [17:17] nacc: okay [17:17] slangasek: +1 [17:18] kirkland: and I like that answer much better than keeping php5 in universe, thanks ;) [17:18] slangasek: it does seem to run, i'm checking all the tests now; it's unclear if it's a regression relative to our php5 status (i'm going to check in a wily lxc) ... as we don't run the tests during build/etc [17:49] hello [17:49] infinity [17:49] are you around? [17:50] hikiko: I am. [17:50] hi :) [17:50] I need your help on something [17:50] there was a bug report that compiz crashes during the upgrade from lts 14 to 16 [17:50] and after some workaround I did with andyrock [17:51] we found out that any desktop crashes [17:51] and the last message we get at compiz is that libc.so is missing [17:52] so, I wanted to test two ideas I had but I don't know much about packaging [17:52] the 1st one: [17:53] hikiko: I'd perhaps like to see the real error message, not a paraphrasing. [17:53] sure infinity, let me find the log, it's andyrock that produced it [17:53] sec [17:57] infinity: Should I make a real patch with the remaining suggestions I have wrt bug #1560577? [17:57] bug 1560577 in glibc (Ubuntu) "Confusing new locale-gen behavior" [High,Confirmed] https://launchpad.net/bugs/1560577 [17:57] GunnarHj: We should talk about it a day that isn't today, probably. [17:58] GunnarHj: I had some mental notes about your last patch, but too busy with Beta to get to the nitty-gritty of it all. [17:58] infinity: Ok, then I'll try to be patient. (I think that last grep() is incorrect, but not sure what it's supposed to do.) [17:59] GunnarHj: It's neither forgotten nor ignored, though, I agree with the spirit of the bug report and patch. [17:59] infinity: Great! :) [17:59] GunnarHj: Most of that code was cargo-culted from our old locale-gen, right or wrong, so also happy to clean up bits that are obviously wrong or pointless. [18:00] https://www.irccloud.com/pastebin/kxQlPlKR [18:00] infinity, ^ [18:00] GunnarHj: I'd like to end up shipping something that has decent backward compat but is also a sane enough delta to push to Debian, so we can stop this forked madness. [18:00] and there was a most recent one from metacity: [18:00] https://www.irccloud.com/pastebin/Wl0AcISq [18:00] infinity: Sounds as a reasonable goal. [18:01] * infinity notes he missed an opportunity to say "stop this forking madness". [18:01] I was wondering if it's possible that since libc went multiarch at the time of the crash the new libc is installed on the system but the dynamic loader looks at the wrong path because it's not updated (searches the old libc paths) [18:02] multiarch was well before 14.04 LTS [18:02] then it can't be that... === jgrimm is now known as jgrimm-afk [18:02] $ lsb_release -rs [18:02] 14.04 [18:02] $ ldd /bin/ls | fgrep libc.so [18:02] libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a0ca70000) [18:03] the other thing I was wondering is if there's any ldconfig missing [18:03] and I found a post inst script that had one commented out [18:03] but I am not familiar with all these might not be libc at all [18:04] Doesn't look like libc's fault in the unity case. The red herring there is that it's trying to debug itself post-crash, using the debug libraries matching what it was linked to in memory. [18:04] but since the gui programs are not responsible for the crash it might be some package [18:04] But it crashed well before it failed to backtrace. [18:05] infinity, I saw some messages about cron [18:05] I couldn't get relevant logs after the crash [18:05] so I recorded the gui upgrade [18:06] do you want me to send you the last frame? [18:06] to see the messages? [18:06] And the metacity one gives me exactly zero info. It's exiting on a SIGPIPE, which implies perhaps that X died. [18:06] yep [18:06] every log i checked gives 0 info :/ [18:06] dmesg, apt logs [18:06] syslog [18:06] X logs? [18:06] no errors [18:06] :/ [18:06] I ll send you the last frame [18:06] Well, the metacity one certainly implies to me that it's X dying, not the window managers. [18:07] And the WMs tend not to do well without a root window to paint. [18:07] yes that's what I believe tooo [18:07] Stupid picky window managers. [18:07] X is dead for sure after the crash [18:07] but there's nothing in the logs [18:07] if I ssh I can see that xserver died [18:08] you can't connect to any display [18:08] but the log is ok [18:08] no errors [18:10] infinity, http://i.imgur.com/A35uMti.jpg [18:10] that isserv warning was in everyone's crash [18:10] It could be that something in the upstart->systemd transition is killing the X server, which would lead to the whole session dying and, potentially, nothing interesting in the X logs. [18:10] btw the udev.postinst:109 needs a fix: double [[]] in the line that takes the basename [18:11] hikiko: The insserv cron warning is also a red herring here (though possibly another bug). [18:11] I have no idea how to make a patch for that... [18:11] yep [18:11] hikiko: And the udev postinst bug is fixed in git, pitti claims it's only cosmetic. [18:11] yes [18:11] that line is never called basically [18:12] I just told you to narrow the warnings [18:12] because I was lost and was checking every single line :/ [18:12] oh! infinity [18:12] andyrock, said that he always sees the crash after udev restarts [18:13] could this be relevant? [18:14] in my screenshot it seems that udev restarts, plus after the crash if i reboot the kernel panic gives the message: "cannot mount root fs" [18:14] hikiko: if unity is trying to trace itself after crash, it's probably doing a poor job of it. Is that what's happened here, like infinity suggests? or is this the output of trying to run compiz under gdb? [18:14] is it possible that the kernel doesnt create an initrd? [18:15] slangasek, I am not sure andyrock did this debugging [18:15] hikiko: no one has reported bugs about missing initrd. The initrd should always be created before the grub config is updated. [18:16] hikiko: so it's possible that compiz is trying to attach gdb to itself automatically, but that it only does this after the crash happens, which is insufficient [18:16] It x crashing [18:16] Not unity [18:16] yes [18:16] x crashes [18:16] ok [18:17] You can reproduce the crash with metaciyy [18:17] so, to debug this, you want to attach gdb to the X server remotely, and capture a backtrace [18:17] I suppose with g-s too [18:17] Now, the real question is if X is *crashing* or being killed externally. [18:17] I tried [18:17] My bet is on the latter. [18:17] But gdb crashes too [18:17] andyrock: how did you run gdb? [18:18] I guess because xorg got updated in the mean time [18:18] and this is where "remotely" probably means "ssh from another machine", since if the X server crashes and blocks the VT you're going to have a hard time switching VTs to see the debug output [18:18] infinity: I guess the latter too [18:24] what looks weird to me is how a gui program like compiz could cause such a big crash that leads to kernel panic, I think that either the updater crashes at the time a critical package is updating and destroys everything (but it wouldn't be the same crash when i add and remove repositories) or a package post upgrade scripts do something that xserver doesn't like [18:25] X crashes or is killed [18:25] There's a kernel panic? No one told me that little tidbit. [18:25] This causes the upgrade crash [18:25] infinity: just on reboot [18:25] infinity, that's afterwards [18:25] on the reboot [18:25] Oh. Kay. [18:25] hikiko: that's secondary [18:25] So it s not relevant [18:26] or possibly unrelated [18:26] alright [18:27] infinity, one other info that made me suspect that multi arch thing is that in i386 there's no crash [18:28] I upgraded successfully [18:28] that's why I thought that it might be some outdated path or sth [18:29] maybe not in libc but somewhere else [18:29] hikiko: Paths to libraries changing under a binary should have zero effect on upgrades, as the current running libraries are locked in RAM (and on disk, just unlinked) until the refcount hits zero. [18:29] There is also a thing about libkbd that had some problems with amd64 [18:29] I at the phone right now [18:29] hikiko: The only exception to that rule being things dlopen()ing libraries at runtime, but if X is doing that to any of its underlying libs after init, it should be taken out and shot. [18:31] hikiko: what we need here is a useful backtrace of the actual crash - whether that's in X or in compiz. If you're reproducing this, can you please ssh into your system remotely and attach gdb to both compiz and X, then upgrade? [18:31] My bet's still on it not being a crash at all but an external signal. [18:31] But that would be nice to confirm, and trace back to the offender. [18:31] I agree with infinity [18:32] because there's no error in the logs [18:32] but I am going to attach the x process to gdb [18:32] from ssh [18:39] hikiko: it will save time if you attach to both compiz and X at the same time, in case we're wrong about it being an X crash [18:41] hikiko: also, please be sure to install libc6-dbg before running gdb [18:41] mmm ok but it will take time [18:42] (the upgrade etc) [18:43] yes, this is why you want to debug both processes in parallel so you don't have to upgrade twice [18:44] I have to reinstall the vm [18:44] because I saved a snapshot [18:44] in the middle of the upgrade to save time [18:44] and I didn't install libc-dbg :/ [18:46] tjaalton: a strange bug I'm experiencing with xorg-server 1.18.2-2ubuntu0.1 from the x-staging PPA - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1561685 [18:46] Launchpad bug 1561685 in xorg-server (Ubuntu) "x-staging: 1.18.2-2ubuntu0.1 host breaks arrow keys on qemu guest" [Undecided,New] [18:47] jderose: ok, thanks for filing it [18:48] tjaalton: np. please let me know if there are any other scenarios you'd like me to test to help you narrow your search [18:49] Get:7 http://us.archive.ubuntu.com/ubuntu xenial/universe DEP-11 64x64 Icons [7,491 kB] [18:49] after release, am i going to be graced with the benefit of downloading 8M of icons quite often ? [18:51] smoser: Well, the ones in the release pocket would never change, one would expect. [18:51] i really know nothing about DEP-11 other than my 'apt-get update' just now downloaded 18M of data, only 10 of which was package data. [18:51] smoser: And apt has gotten quite good about not even hitting things that haven't changed. === jgrimm-afk is now known as jgrimm [18:52] s/me guesses thats somehow related to gnome-software replacing the sw-center [18:52] and this new data is not goign to be changing any more frequently than apt package data ? [18:52] slangasek I'll leave the upgrade finishing and I'll email it to you tomorrow because it's almost 21:00 here and the installation + upgrade with 2 processes attached to gdb will take ages [18:52] i was very happy to find apt not downloading as much stuff as it used to, and then it started ownloading 10s of Meg of icon data that i'll never look at. [18:52] I guess more than 2hrs [18:54] smoser: so far I have the impression that you can simply delete or truncate /etc/apt/apt.conf.d/50appstream to avoid the giant tarball of icons [18:55] smoser: there may be a clever dpkg redirect option too that would prevent the config file from being installed in the first place, but that kind of 'old dpkg magic' feels shrouded in mists.. :) [18:58] jderose: well, if you could bisect the point-release commits that would be great [18:59] tjaalton: sure. what's the best way to do this? [19:03] tjaalton: i can figure it out, but if you have any tips, i'd appreciate them. where is the packaging repository for the x-staging PPA hosted? [19:03] hikiko: understood, thanks [19:03] jderose: i've used a patch which partly reverts the update, and then change the point to "bisect" [19:05] jderose: same place as debian [19:05] control file has the url [19:05] okay, thanks === matsubara is now known as matsubara-afk [19:43] where on the live image do I find the ubiquity-dm startup sequence? [19:43] I'm trying to launch it by hand, but I don't see how to make it start the language selector [20:01] slangasek: so we're already two updates behind current drupal7 ... (debian unstable has 7.43-1). Based upon https://api.drupal.org/api/drupal/CHANGELOG.txt/7, I'm not 100% on needing a FFe for it (mix of bugfixes and feature improvements, i think), but would you prefer we wait for 7.44, presuming i can figure out if that will be soon? i'm guessing that version will have the php7 changes, but not sure [20:01] on that yet. In the meanwhile, i've got the simple debdiff that modifies the control file as it is now, and does work in my basic testing (although it's unclear if a bunch of stuff is broken in the various modules). [20:20] Pharaoh_Atem: on reading: https://github.com/kohana/core/issues/642#issuecomment-151244760, can we drop all of libkohana? [20:20] Pharaoh_Atem: no reverse deps in the archive, that i can see [20:25] minimially it seems like the versions we have in the archive are unsupported [21:06] mterry, are they still stuck? archive is currently frozen for the beta === matsubara-afk is now known as matsubara [21:20] nacc: should have an FFe; can be fairly pro forma, of the style "if we don't update to the new upstream version, we don't get php7 compatibility (or security support, or installability)" [21:24] slangasek: ok, i'll try and get in touch with the upstream developers to see if 7.44 will have the requried fixes or not ... and i've asked a few that have commented in antoher bug to see if they can test what we have [21:53] nacc: so Kohana is dead then [21:53] Pharaoh_Atem: well, that' the thing [21:54] i think it's *not* dead :) [21:54] but no one updated the issue [21:54] 3.1 and 3.2 are dead, or at least, from the old kohana structure [21:54] they reorged and are doing releases again [21:54] but i think only unpacakged version support php7 :/ [21:54] oh dear [21:54] 3.3 and 4.0-dev [21:54] but no packages in the archive depend on them [21:55] so not sure it matters too much, and no one has requested or tried to pakcage 3.3, it seems [21:56] hmm [21:57] nacc, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg see php-json on the right side [21:57] doko: yep, it's on my list to figure out ... dh-php5 is going to be gone, but it's part of php5 [21:58] doko: also, i think it's a false positive, possibly, as php-json itself is now part of php7, but there was a php-json that was its own package with php5 [21:58] nacc, tell me if a nag too much ;p [21:58] doko: no it's good! it's just a lot going on at the same time :) [22:01] doko: it will clear out once we can push src:php-json to universe, which will happen once i rebuild the revdeps on php5-json :) [22:01] and then it will get removed from the archive anyways [22:01] doko: i've been going alphabeticall through the revdeps of src:php5, but will switch tack once i finish the l's, to cleanup that and the NBS [22:12] Pharaoh_Atem: just contacted upstream kohana developer, even the offical 3.3.5 doesn't support php7, only his private fork does [22:12] Pharaoh_Atem: 4.0.0 will, but doesn't exist [22:13] well, that's problematic, then [22:13] if it doesn't exist, it'll probably need to be yanked [22:13] Pharaoh_Atem: yep, already requested [22:14] nacc: as for dh-php5 and php-json, they can just die :) [22:14] Pharaoh_Atem: yes, they will [22:14] Pharaoh_Atem: there are many revdeps to resolve first [22:14] can't just break the archive [22:16] php-json is php-pecl(json) (aka, Remi's php-pecl-jsonc), which is no longer required and php7.0-json is a fully equivalent provider [22:16] Pharaoh_Atem: yes, i know [22:16] Pharaoh_Atem: that's not good enough [22:16] Pharaoh_Atem: we have to ifx the packages [22:16] ah, right [22:16] php5-cli is still in the archive and depends on php5-json [22:16] as does php5-cgi [22:16] and of course, all the extensions and apps [22:18]