| * RAOF continues to not be an archive admin. | 02:02 | |
| * RAOF continues to need to resolve that situation. | 02:02 | |
| mwhudson | yes please, an AA in my timezone (ish) would be useful at times :-) | 03:08 |
|---|---|---|
| Mirv | thanks doko. yes still some problem somewhere.. | 05:27 |
| Mirv | RAOF: right, sounds familiar to me from some months ago.. | 05:30 |
| Mirv | seb128: morning! if you're about, please try if you can find some time to get this Qt & KDE transition through.. we're now down to very small selection of update_output.txt I think | 06:20 |
| Mirv | not counting eg amd64 list that lists some kde language packs, the update_output.txt claims for example i386: camitk-actionstatemachine, camitk-imp, itksnap, jacktrip, kde-spectacle, kubuntu-desktop, kubuntu-full, libcamitk4, libcamitk4-dev, lubuntu-qt-desktop, lxqt-config, nifti2dicom, nifti2dicom-dbg, nomacs, plasma-discover, qnifti2dicom, reminders-app | 06:21 |
| Mirv | it's starting to be really hard for me to see any problems with those, but for reminders-app I believe it should be removed as I asked in bug #1606531 - it's the only package still depending on transitional package qtdeclarative5-quicklayouts-plugin removed in yakkety-proposed | 06:23 |
| ubot5 | bug 1606531 in reminders-app (Ubuntu) "RM: transitional QML module packages" [Undecided,New] https://launchpad.net/bugs/1606531 | 06:23 |
| Mirv | others have picked up Qt 5.6 dependency during build time so they'd need to migrate too, but I don't see any problems with them | 06:23 |
| Mirv | lxqt-config needed rebuild to transition to libkf5screen7 from libkf5screen6 | 06:39 |
| Mirv | lubuntu-desktop refuses to install because of some (weird?) problem in installing usb-modeswitch, but I can't see why lubuntu-desktop itself would be required to migrate at the same time | 06:39 |
| Mirv | maybe that's noise in update_output, I've never been good in parsing that file | 06:40 |
| Mirv | but reminders-app (source and binaries) needs to be removed from yakkety, so please do that | 06:40 |
| Mirv | we'd definitely need a more eastern archive admin.. | 07:11 |
| Ukikie | Mirv: Howdy. | 07:18 |
| Mirv | Ukikie: oh hi! | 07:19 |
| Mirv | ok, so Lubuntu and Kubuntu seeds need to be updated to not depend on obsolete packages | 07:52 |
| Mirv | meanwhile, archive admins still please remove reminders-app from yakkety | 07:52 |
| sil2100 | We still had that in the archives? | 07:54 |
| Mirv | sil2100: yes, I've asked for its removal at bug #1606531 | 07:59 |
| ubot5 | bug 1606531 in reminders-app (Ubuntu) "RM: transitional QML module packages" [Undecided,New] https://launchpad.net/bugs/1606531 | 07:59 |
| Mirv | I have updated Kubuntu and Lubuntu meta packages and plasma-discover's erronous transitional packages. | 08:18 |
| Mirv | I'm still worried about the remaining packages in update_output.txt and would welcome help in understanding the list and if any of it is serious or not | 08:19 |
| cjwatson | LocutusOfBorg: Thanks for dealing with Haskell. | 09:28 |
| LocutusOfBorg | cjwatson, please wait for it to finish before thanking me ;) | 09:28 |
| cjwatson | LocutusOfBorg: Are you working in order on http://people.canonical.com/~ubuntu-archive/transitions/ghc.html ? Some surprisingly high-up red there. | 09:29 |
| cjwatson | LocutusOfBorg: Oh, it normally takes a week or so, I wasn't rushing you :) | 09:29 |
| LocutusOfBorg | actually I took a different approach | 09:29 |
| LocutusOfBorg | see in update_excuses what was uninstallable | 09:29 |
| LocutusOfBorg | and rebuild them | 09:30 |
| cjwatson | I find that inordinately hard on my brain. | 09:30 |
| LocutusOfBorg | now, I'm sorting the unbuildable packages and retrying them in the right order | 09:30 |
| cjwatson | The transition tracker is a much easier format. | 09:30 |
| LocutusOfBorg | yes, I know thanks, but I prefer to see logs, and understand them this time | 09:30 |
| LocutusOfBorg | next time for sure I'll see the tracker and trust it ;) | 09:30 |
| LocutusOfBorg | the main goal is to understand things now | 09:31 |
| cjwatson | It is true that there are a couple of things on the tracker that you have to know to ignore. | 09:31 |
| cjwatson | agda* on some architectures and xcffib (due to lack of versioned-provides support in that ben instance) IIRC. | 09:32 |
| LocutusOfBorg | actually I could build-and-retry-build until stuff is sorted out I guess | 09:33 |
| LocutusOfBorg | each time waiting for dinstall | 09:33 |
| LocutusOfBorg | but I prefer the slow "check-each-package" method | 09:33 |
| LocutusOfBorg | BTW the graphic might have one single big "retry all builds" button instead of clicking on each architecture | 09:34 |
| cjwatson | I just use ubuntu-build for that. | 09:34 |
| LocutusOfBorg | and also one "no change rebuild and upload" :) | 09:34 |
| cjwatson | And a script for that :) | 09:34 |
| LocutusOfBorg | yep me too | 09:34 |
| cjwatson | LocutusOfBorg: The problem with not going in order by layers is that you can end up duplicating builds if something in a higher layer fails on some architectures. | 09:34 |
| LocutusOfBorg | but it might unify the "rebuild messages" | 09:34 |
| cjwatson | I don't care about that. | 09:35 |
| cjwatson | LocutusOfBorg: e.g. there's a lot of noise from haskell-vector failing to build on a few arches, which needs to be sorted out before rebuilding anything that b-ds on it | 09:35 |
| LocutusOfBorg | true | 09:35 |
| cjwatson | Exciting that it manages to run out of memory on the big arches. | 09:36 |
| Mirv | cjwatson: can you remove src:reminders-app and its binaries from yakkety? | 09:36 |
| cjwatson | sorry, I know you're looking around desperately for an AA but I think that's more phone context than I have time to import into my brain at the moment ... | 09:37 |
| cjwatson | well, maybe this one is simple, moment | 09:37 |
| Mirv | cjwatson: it is simple, no reverse depends and has lived only in click space since 2014 | 09:38 |
| Mirv | has an old transitional dependency being dropped, so it would be time to get rid of it for good | 09:39 |
| cjwatson | Mirv: ok, done that one but I'm not going to look at the rest of that bug at the moment | 09:39 |
| Mirv | cjwatson: no problem, none of that other is urgent | 09:40 |
| Mirv | and sorry for sounding desperate, it's just because I am :) | 09:41 |
| Mirv | but making progress too | 09:41 |
| cjwatson | LocutusOfBorg: you probably want to chase up haskell-vector with #debian-haskell if you haven't already; the discrepancy in which arches it manages to succeed on between Debian and Ubuntu is odd, but maybe it needs to be just a whitelist of arches with good enough compiler support or something instead | 09:41 |
| LocutusOfBorg | actually I'm retrying them | 09:43 |
| LocutusOfBorg | lets see how they go | 09:43 |
| cjwatson | I doubt that will make any difference, but ICBW. | 09:43 |
| LocutusOfBorg | moved to #-haskell | 09:48 |
| === mcasadevall is now known as NCommander | ||
| === kip_ is now known as kip_brb | ||
| Mirv | when some archive admin reads the whole today's backlog, I'd like to add I don't know if there's any fix for fulfilling camitk's powerpc dependency which fails to build in proposed due to something not related to these landings: https://launchpad.net/ubuntu/+source/camitk/4.0.0~beta-2build1 -> https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-2ubuntu1 | 10:38 |
| Mirv | so I'd like to ask considering any measures needed for getting the transition done regardless | 10:39 |
| LocutusOfBorg | camitk is not a blocker for the transition I guess | 10:40 |
| LocutusOfBorg | Mirv, do you have another opinion? AFAIR I did the rebuilds correctly, and they wre stuck because of qt transition | 10:40 |
| LocutusOfBorg | no need to retry itk4 | 10:41 |
| Mirv | LocutusOfBorg: well they show up in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt , and I noticed it built in release pocket but not in proposed, so it would block | 10:41 |
| * Mirv needs to go for 45mins now | 10:41 | |
| Mirv | LocutusOfBorg: but yes I think the release pocket camitk should work fine and I have it installed on my yakkety-proposed, I'm just wondering about the update_output.txt | 10:42 |
| Mirv | so maybe that's noise | 10:42 |
| LocutusOfBorg | they show up there, because the qt is not over | 10:42 |
| LocutusOfBorg | for sure you don't need to remove powerpc, since it is already removed, neither retry itk4 there | 10:44 |
| LocutusOfBorg | a no change rebuild against qt for every arch might be needed, but please talk to qt folks | 10:44 |
| LocutusOfBorg | I can say, from *my* itk4 side, everything should be good and in place | 10:45 |
| Mirv | LocutusOfBorg: there's no qt folks but me | 10:46 |
| LocutusOfBorg | oh... ok :) | 10:46 |
| Mirv | LocutusOfBorg: ok, I'll try to fix everything else and see if that keeps visible in the output.txt or not in the easy autohinter section | 10:46 |
| LocutusOfBorg | thanks, but AFAIK you might need a no-change rebuild for it and itksnap | 10:47 |
| LocutusOfBorg | and nifti2dicom | 10:47 |
| LocutusOfBorg | (I didn't try the above, I don't know how you uploaded the transition and which packages needs rebuilds) | 10:48 |
| === kip_brb is now known as kip_ | ||
| Mirv | why is btw publisher runs taking >1h nowadays at times? and almost never the 15-20mins it used to be | 11:41 |
| Laney | Mirv: looks like there are quite some issues remaining | 12:00 |
| === maclin1 is now known as maclin | ||
| acheronuk | Mirv: a package for frameworks backport took 3hrs to publish on LP yesterday. despite people saying it's fine, it's clear there is some big issue with the publisher | 12:04 |
| Mirv | Laney: yep, help would be welcome fixing those. many are being fixed, but there is for example /usr/bin/ld.gold: --secure-plt: unknown option on powerpc that comes from GCC6, and I don't know how to even workaround that https://launchpadlibrarian.net/277744096/buildlog_ubuntu-yakkety-powerpc.ubuntu-ui-toolkit_1.3.2030+16.10.20160726.4_BUILDING.txt.gz | 12:06 |
| Mirv | acheronuk: ack. | 12:07 |
| Mirv | Laney: and I don't know what would be actually wrong with many of the packages that LocutusOfBorg mentioned, I'm trying a no-change rebuild now even though I can't find anything wrong with the packages and I have them installed on my yakkety-proposed | 12:07 |
| Mirv | acheronuk: I think it's been getting worse and worse, but there has been some amount of issues for weeks | 12:09 |
| Laney | Mirv: camitk is the new insighttoolkit4 no? | 12:10 |
| Laney | Mirv: And the previous one didn't build on powerpc/ppc64el either, so that shouldn't matter | 12:11 |
| LocutusOfBorg | my transition is fine | 12:11 |
| acheronuk | Mirv: definitely. that was just an extreme example yesterday, but indeed it's been frequently > 1hr for many weeks now and even perhaps degrading more | 12:12 |
| LocutusOfBorg | at least AFAICT | 12:12 |
| Laney | LocutusOfBorg: Which one? | 12:12 |
| LocutusOfBorg | insighttoolkit4 rebuilds | 12:12 |
| Mirv | Laney: it build depneds on libinsighttoolkit4. so yes I think those shouldn't matter, but can you explain why they are shown in the update_output.txt among with packages that actually have installibility problems? in the Trying easy from autohinter section. | 12:12 |
| Mirv | LocutusOfBorg: for better or no change, now the rebuilds (I did in a silo) are copied over. | 12:13 |
| LocutusOfBorg | ok | 12:13 |
| Laney | I think this ffmpeg is going to clear out some of them (libwebp5 -> 6) | 12:14 |
| Mirv | ok, and we're getting the kde langpack updates right now too. but that leaves that one powerpc problem preventing ubuntu-ui-toolkit rebuild to fix a s390x problem that would prevent the whole promotion, at minimum | 12:14 |
| Mirv | ..unless you could force ubuntu-ui-toolkit-autopilot/s390x uninstallability (coming from the upstart problem and newest removals for s390x for it) to get this inch forward before world breaks again | 12:15 |
| cjwatson | acheronuk: What package name? | 12:16 |
| Mirv | cjwatson: for example https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6786564/+listing-archive-extra | 12:16 |
| Mirv | that's probably 1.5h by now | 12:16 |
| Mirv | since build finished | 12:16 |
| cjwatson | I want specifically acheronuk's example from yesterday. | 12:16 |
| Mirv | ok | 12:16 |
| cjwatson | Anyway, the thing is normally that it isn't anything very specific, it's death by a thousand cuts. | 12:17 |
| acheronuk | cjwatson: kxmlgui in https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-frameworks I think? | 12:20 |
| acheronuk | maybe LP rounds to hrs after a point, but it did clearly say when still unpublished "Finished 3 hours ago (took 3 minutes, 48.5 seconds)" | 12:22 |
| cjwatson | The >1hr run just recently seems to have been mostly due to some very large libreoffice publications which took a long time to shift around internally. | 12:22 |
| acheronuk | seems quite consistently closer to the 1hr than the old 20 (ish) mins nowadays. i.e. when it publishes in the 20 mins or so it used to, it's a surprise, rather than the norm | 12:26 |
| cjwatson | The Kubuntu PPAs are some of our largest, so you're going to see a somewhat skewed view. | 12:28 |
| cjwatson | Looking for the kxmlgui case. | 12:29 |
| acheronuk | cjwatson: yes, I know is a perception thing as well | 12:29 |
| cjwatson | acheronuk: As I suspected, the kxmlgui case is an anomaly. There's a weekly window where we do more time-consuming cleanup and when the normal publisher doesn't run, and you happened to run into that. | 12:31 |
| cjwatson | Starts at 0559 on Sundays and normally takes a few hours. | 12:31 |
| cjwatson | Unrelated to Mirv's question. | 12:32 |
| acheronuk | cjwatson: understood, and I except things like can/do happen. just that on top of the quite clear degrading of the times over the last few weeks/months made that one stand out! | 12:32 |
| cjwatson | Anyway, as far as I can tell there are no easy fixes. We do have a plan to restructure things so that we can scale much better, but it is quite a large piece of work so no timescale yet. | 12:33 |
| cjwatson | That's "diskless PPAs", so we'd start serving files out of the cloud and wouldn't have to rely so much on shifting lots of files onto a single giant system. | 12:34 |
| acheronuk | cjwatson: again, understood. sometimes there is a simple cause and a simple fix. sometimes, like this as it sounds, it's not that easy. | 12:35 |
| acheronuk | it's just a tad frustrating when trying to build anything together with a complicated/long dependency tree | 12:37 |
| cjwatson | Definitely. | 12:37 |
| cjwatson | This is a case of suffering from our own success. | 12:37 |
| cjwatson | And I don't mind looking into it because sometimes there is an obvious cause. | 12:37 |
| cjwatson | I would love to get time for diskless PPAs. With any luck it will be months not years ... | 12:38 |
| ogra_ | can someone bump the score on https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2573 ? it tells me it will start in 20min since about 3h now ... (and i'm having the same issue with all arm builds since friday) | 12:55 |
| cjwatson | ogra_: done | 13:07 |
| ogra_ | thanks ... is there an archive rebuild going on ? | 13:07 |
| cjwatson | no | 13:07 |
| ogra_ | (since this happens since friday already) | 13:08 |
| ogra_ | (also for arm64) | 13:08 |
| cjwatson | arm64 and armhf are the same builder pool. | 13:08 |
| ogra_ | ah | 13:08 |
| cjwatson | Maybe we need to make another attempt to get approval for more Moonshot hardware now that we're actually using it. | 13:11 |
| ogra_ | +1 | 13:12 |
| ogra_ | well, something changed since friday, before my arm builds were rather fast | 13:17 |
| ogra_ | ARGH ... and i forgot to bzr push before triggering the build ... sigh | 13:17 |
| cjwatson | ogra_: Just looks like more builds happening really. | 13:21 |
| ogra_ | hmm, k | 13:22 |
| ogra_ | cjwatson, could you bump https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2575 too ? sorry, the firt one was actually wasted | 13:22 |
| ogra_ | *first | 13:23 |
| cjwatson | See, now you're not stuck in traffic, you *are* traffic ;-) | 13:23 |
| cjwatson | done | 13:23 |
| ogra_ | haha | 13:23 |
| LocutusOfBorg | cjwatson, do you happen to know what is going on there? https://launchpad.net/ubuntu/+source/haskell-http-link-header/1.0.1-1build3/+build/10569477 | 13:28 |
| cjwatson | LocutusOfBorg: Nope. | 13:29 |
| cjwatson | LocutusOfBorg: You could try cancelling it and seeing if it works on a different builder; sagari has somewhat different hardware from the others. | 13:29 |
| LocutusOfBorg | that was my wondering. | 13:30 |
| LocutusOfBorg | rescheduling, but I can't force a particular builder | 13:30 |
| cjwatson | No, but you have an 8/9 chance | 13:30 |
| LocutusOfBorg | fair enough :p thanks | 13:31 |
| cjwatson | (I can force it if I have to, but it's cumbersome so I'd rather not bother) | 13:31 |
| LocutusOfBorg | nah, it is fine | 13:32 |
| Mirv | can someone figure out why usb-modeswitch refuses to install on yakkety-proposed? it's a real mystery to me. | 13:36 |
| Mirv | oh, ok, the -data has Breaks on usb-modeswitch << 2.4.0 | 13:37 |
| Mirv | so that breaks installing lubuntu-qt-desktop, shown also in update_output.txt but should be noise since it's not related to Qt and KDE upgrading | 13:38 |
| Mirv | does anyone know, that if update_output.txt does list eg lubuntu-qt-desktop there as being uninstallable, will it need manual intervention from archive admin via hints if I'd like Qt & KDE to migrate? | 13:39 |
| Mirv | oh, but, new lubntu-qt-desktop is required so that its erronous dependencies on obsolete KDE packages would be dropped :( | 13:40 |
| Mirv | cyphermox: would it be a really quick job for you to update usb-modeswitch in Ubuntu, ie sync with Debian, so that ^ blocker for Qt and KDE transition would be gone? | 13:40 |
| Mirv | it starts to seems I need to fix all of proposed for all packages before this is going to work :( | 13:41 |
| cyphermox | most definitely not a quick job right now | 13:41 |
| Mirv | hmm, I wonder if I could revert usb-modeswitch-data then | 13:41 |
| cyphermox | and I really don't understand why it's a blocker for anything, it really shouldn't be, especially not Qt/KDE stuff | 13:41 |
| Mirv | cyphermox: because lubuntu-qt-desktop depends on installability of usb-modeswitch, and lubuntu-qt-desktop needs to be updated to drop KDE dependencies that are broken | 13:42 |
| Mirv | so if lubuntu-qt-desktop cannot be installed, update_output.txt claims it's Qt's / KDE's fault | 13:42 |
| Mirv | also lubuntu-qt-desktop could temporarily lose its usb-modeswitch dep, that'd be another workaround | 13:43 |
| Mirv | I'll just go and do something if no-one wants to help | 13:43 |
| xnox | .. | 13:47 |
| xnox | please remove dbus-cpp... should be for yakkety | 13:47 |
| cyphermox | Mirv: I would suggest you revert -data, it's the best thing to do | 13:48 |
| Laney | Is it intentional that component-mismatches wants to promote the first alternative of an or-ed dependency group if one of the others is in main already? | 13:50 |
| Laney | i.e. should I fix the report or the package? | 13:50 |
| Mirv | cyphermox: ok, thank you | 13:52 |
| cjwatson | Laney: component-mismatches doesn't care what's already in main; it does a from-scratch analysis with germinate | 13:53 |
| cjwatson | Laney: making it care about the current component overrides would produce weird hysteresis, I think | 13:53 |
| cjwatson | (and would be difficult anyway ...) | 13:54 |
| Laney | cjwatson: Righto. | 13:54 |
| Mirv | still not anyone willing to decipher the update_output.txt remaining problems? so I was interested in why in the autohinter section eg camitk / itksnap would be listed, and also if there's any possibility of ignoring s390x installability issue of ubuntu-ui-toolkit-autopilot for one time if it seems the real fix would take another week or so. | 14:42 |
| Mirv | throughout the day I've been able to progress on my own though in many places, but it may be I'm at the end of the road now | 14:43 |
| Laney | Mirv: I uploaded ffmpeg and some other bits to progress it somewhat (should fix camitk) | 14:44 |
| Mirv | Laney: ok, thank you. what was the problem with it? | 14:45 |
| Laney | webp transition | 14:45 |
| Mirv | oh so probably somewhere from the depths of that libinsighttoolkit | 14:46 |
| Laney | I forgot the chain, but something in there was depending on libwebp5 | 14:46 |
| Laney | No doubt there are one or two other bits left for that one; didn't check | 14:47 |
| Mirv | anyway, it may be that the UITK s390x issue would be the last one after things settle, but I can't rebuild UITK because of powerpc GCC6 issue, and I can't seem to find a workaround to force it. a real fix would probably be something in qtbase, updating of which would relaunch thousands of autopkgtests and probably find both flaky tests and gcc6 issues, postponing this migration by another week or | 14:47 |
| Mirv | three | 14:47 |
| Laney | which hint block are you looking at? | 14:47 |
| Mirv | Laney: easy: 260+0: a-56:a-31:a-31 | 14:48 |
| Laney | ok, let's see | 14:48 |
| jbicha | if you need webp first, more uploads are needed https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libwebp.html | 14:49 |
| Laney | just need a minute to set up the script on snakefruit, since my PC is out of reach | 14:49 |
| Laney | yep | 14:49 |
| jbicha | bug 1610066 | 14:49 |
| ubot5 | bug 1610066 in gst-plugins-bad1.0 (Ubuntu) "gst-plugins-bad1.0 ftbfs on yakkety" [High,New] https://launchpad.net/bugs/1610066 | 14:49 |
| Mirv | now search for "easy: 245+0: a-47:a-30:a" but actually just search for qtbase in reverse, the last hit is the best looking hint block | 15:24 |
| Mirv | I need to rest now. | 15:24 |
| Laney | Mirv: I think the plasma-discover depends on packagekit >= 1.0 is going to cause you trouble | 15:59 |
| seb128 | not close to see the end of that transition... | 16:05 |
| seb128 | Laney, did you get a reply from the unity8 team about click and yakkety? | 16:06 |
| Laney | No. | 16:07 |
| Laney | Nothing useful | 16:07 |
| seb128 | :-/ | 16:07 |
| Laney | I'm not happy about this being pushed back again after it was agreed | 16:07 |
| seb128 | I don't think any agreement was changed | 16:09 |
| seb128 | the phone team is not planning devices on yakkety and is fine getting that to regress | 16:09 |
| seb128 | the issue is the new usecase of our (desktop) team wanting unity8 on the default install this cycle now | 16:10 |
| Laney | So a new requirement is making the previous agreement insufficient | 16:10 |
| seb128 | yes | 16:10 |
| seb128 | well it's up to us | 16:11 |
| seb128 | we can declare that we don't need click | 16:11 |
| seb128 | it's just that today we only have click as a working package installer in unity8 | 16:11 |
| Laney | We have to either do it, or undo what's happened in proposed | 16:11 |
| seb128 | no gnome-software working nor snaps dash integration | 16:11 |
| Laney | Assuming this plasma dependency is legitimate, that implies some work there | 16:12 |
| seb128 | willcooke, ^ we need to make a call on that | 16:12 |
| willcooke | seb128, on what exactly? Your "no g-s working.." comment has confused me | 16:14 |
| seb128 | willcooke, read the backlog from 16:59 on | 16:15 |
| willcooke | I did, I'm still not sure what you're asking | 16:15 |
| willcooke | is it "do we move to PK 1.0" in 16.10? | 16:16 |
| seb128 | willcooke, but summary is that the pkgkit 1.0 transition in yakkety-proposed blocks other things including qt/kde stack | 16:16 |
| seb128 | yes | 16:16 |
| willcooke | in which case, yes | 16:16 |
| willcooke | yes we move | 16:16 |
| willcooke | end of | 16:16 |
| seb128 | k | 16:16 |
| willcooke | tedg is hoping to land support in u8 by EOW | 16:16 |
| seb128 | so no way to install packages today under unity8-desktop | 16:16 |
| seb128 | which is fine | 16:16 |
| seb128 | k | 16:16 |
| Laney | if it generates pressure to get the work done faster | 16:16 |
| Laney | ;-) | 16:16 |
| seb128 | dobey said it was some thousand lines of code to review and was probably not going to be that easy | 16:16 |
| seb128 | but let's see | 16:17 |
| Laney | it's the right call for our team imho | 16:17 |
| Laney | thanks! | 16:17 |
| * Laney gives Mirv a shoulder massage | 16:17 | |
| seb128 | Laney, either that, or it creates pressure on our team to fix things that we broke | 16:17 |
| Laney | sorry | 16:17 |
| willcooke | attent_e looked at what was needed to get g-s working under u8 too | 16:17 |
| seb128 | but yeah, I agree we should do it | 16:17 |
| seb128 | just be ready to get some heat for breaking things | 16:18 |
| willcooke | but if ted_g is working on a u8 native option, so much the better | 16:18 |
| seb128 | and have to figure a way out | 16:18 |
| Laney | It's not as if there hasn't been an interminable amount of warning about this problem | 16:18 |
| seb128 | right | 16:18 |
| seb128 | well as said we (desktop) are in charge now of seeding that new session and getting it to work | 16:18 |
| willcooke | Laney, +1 - we've been talking about it from before this cycle even started | 16:18 |
| seb128 | so it's selftwarning at this point | 16:18 |
| seb128 | but we haven't really been on top of that work (yet) | 16:19 |
| seb128 | anyway the session is what it is | 16:19 |
| seb128 | then we can start discussing bugs between unity8 team and us | 16:19 |
| seb128 | Laney, willcooke, thanks for pushing and acking, I think landing it now is the right thing, we delayed enough | 16:29 |
| Laney | seb128: merci | 16:29 |
| seb128 | the number of transitions/work that still need to land start being a bit concerning but I guess we can sort out after feature freeze starts | 16:29 |
| wxl | infinity: a member of our lubuntu team has created merge proposals to implement qt-driven images for lubuntu. this is the future of lubuntu, so it would be really great to have. what's the timeline on this? https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/lubuntu-next-image/+merge/301203 https://code.launchpad.net/~tsimonq2/livecd-rootfs/lubuntu-next-image/+merge/301202 | 17:40 |
| === ochosi_ is now known as ochosi | ||
| bdmurray | tjaalton: Could you have a look at bug 1610434? | 20:25 |
| ubot5 | bug 1610434 in xorg-lts-xenial (Ubuntu) "Ubuntu GNOME Trusty HWE upgrade fails to install libwayland-egl1-mesa-lts-xenial" [High,Triaged] https://launchpad.net/bugs/1610434 | 20:25 |
| doko_ | we need somebody to track the OpenGLes build failures on arm64 ... and remove the packages which don't build anymore | 22:30 |
| doko_ | this is a blocker for transitions, e.g. https://launchpad.net/ubuntu/+source/tulip/4.8.0dfsg-2build4 | 22:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!