| === salem_ is now known as _salem | ||
| === kickinz1 is now known as kickinz1|afk | ||
| cyphermox | @pilot out | 02:36 |
|---|---|---|
| === 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: | ||
| hallyn | pitti: hi - so debian bug 777649 has the long sordid tale of trying to get an important cgmanager fix into jessie. Looks like we're finally there. Would you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u1.dsc ? | 03:33 |
| ubottu | Debian bug 777649 in release.debian.org "unblock: cgmanager/0.33-2+deb8u1" [Normal,Open] http://bugs.debian.org/777649 | 03:33 |
| hallyn | (into testing) | 03:33 |
| tnkhanh | Hi when will 14.04 have Java 8 | 04:58 |
| tnkhanh | I mean to install from apt-get | 04:58 |
| tnkhanh | hello anyone? | 05:08 |
| pitti | hallyn: yay, good | 05:32 |
| pitti | hallyn: will do, but have to create a jessie schroot first | 05:33 |
| tnkhanh | Hi when will 14.04 have Java 8 | 06:11 |
| tnkhanh | anyone? ==' | 06:11 |
| === kickinz1|afk is now known as kickinz1 | ||
| LocutusOfBorg1 | good morning to everybody | 08:03 |
| Unit193 | Howdy. | 08:06 |
| === rcj is now known as Guest33360 | ||
| Mirv | tjaalton: Qt 5.4 landed with your openvg build dep removal included | 08:34 |
| tjaalton | Mirv: great | 08:34 |
| pitti | tjaalton: http://people.canonical.com/~ubuntu-archive/nbs.html \o/ | 08:38 |
| * pitti sheds a tear of joy | 08:38 | |
| pitti | that must be the earliest "empty NBS" of all releases : | 08:39 |
| pitti | :) | 08:39 |
| pitti | hallyn: uploaded | 08:47 |
| === tsdgeos_ is now known as tsdgeos | ||
| tjaalton | pitti: enjoy while it lasts :) | 09:05 |
| joern_ | hi everyone! | 09:57 |
| joern_ | I'm looking for someone who could help debugging/triaging a problem with Ubiquity... maybe I should introduce myself, I am Jörn and I help the Lubuntu team. I've created a live iso with LXQt as a tech preview, but Ubiquity refuses to start (both GTK/KDE versions), and there seems to be no log file entry even with --debug | 09:59 |
| joern_ | Tim from Ubuntu Gnome mentioned the name xnox :D are you or some other able to help me? | 10:00 |
| xnox | joern_: depends what with. | 10:11 |
| xnox | joern_: in general ubiquity knows only about certain types of DEs / environments. Is LXQt Qt5 or Qt4? | 10:12 |
| xnox | joern_: you should see logs in /var/log/installer/* as well as messages in /var/log/syslog | 10:12 |
| joern_ | hi xnox | 10:13 |
| joern_ | LXQt is now Qt5 only | 10:13 |
| joern_ | there are no messages in /var/log/syslog (even with --debug) | 10:14 |
| joern_ | wasn't /var/log/installer the place for logs on an installed system? | 10:15 |
| joern_ | the only kind of error I get is (I'm not sure if it is important): "umount: /run/udisks2/inhibit-polkit: not mounted" | 10:17 |
| joern_ | paste.ubuntu.com/10271088 | 10:20 |
| joern_ | that is /var/log/syslog after running Ubiquity with --debug | 10:20 |
| joern_ | there is no folder /var/log/installer | 10:20 |
| joern_ | anything more informations I could give you? | 10:21 |
| geser | pitti: a systemd question: as I permanently moved to systemd (and purged upstart instead of keeping it in removed state), I tried yesterday to boot with upstart but it sort of failed (only two messages visible on the terminal, otherwise blank and no boot progess visible, like starting lightdm). Booting with upstart should continue to work even after switching, right? | 10:39 |
| pitti | geser: right, with upstart-bin | 10:39 |
| pitti | hm, wait | 10:40 |
| pitti | I have it removed, but not purged | 10:40 |
| pitti | geser: indeed, the "upstart" package contains a ton of /etc/init/ jobs | 10:40 |
| pitti | which one actually needs for booting with upstart | 10:40 |
| pitti | geser: so these would need to move into upstart-bin or a new binary pacakge, or we need to put upstart's /sbin/init into a different binary | 10:42 |
| geser | I guess I should switch back to upstart, then install systemd-sysv again to have upstart in removed state (for now) to have a working upstart fallback | 10:43 |
| geser | pitti: should I file a bug (against upstart) about it? | 10:45 |
| pitti | geser: yeah, can't hurt | 10:48 |
| tnkhanh | Hi when will 14.04 have Java 8 | 11:01 |
| tnkhanh | I mean to install from apt-get | 11:01 |
| === _salem is now known as salem_ | ||
| === MacSlow is now known as MacSlow|lunch | ||
| bluesabre | pitti, would you mind reviewing https://bugs.launchpad.net/lightdm-gtk-greeter-settings/+bug/1295405 for inclusion in vivid? If possible, the xubuntu team would like to upload this to the archive and include it in the seed for this release. As I understand it, the Mate team is also interested in including this utility | 12:12 |
| ubottu | Launchpad bug 1295405 in Settings editor for LightDM GTK+ Greeter "[needs-packaging] Package and upload to vivid" [Wishlist,In progress] | 12:12 |
| pitti | bluesabre: sorry, busy; can you please just put it into the sponsoring queue? | 12:23 |
| bluesabre | pitti: np, I've subbed ubuntu-sponsors, so it should be visible | 12:24 |
| bluesabre | thanks for getting back to me so quickly | 12:24 |
| === MacSlow|lunch is now known as MacSlow | ||
| jbassett_ | Hello all | 13:10 |
| jbassett_ | Is this a place where I may make a suggestion, I do not believe it is a bug, more likely just not a realised use case I have a query about? | 13:10 |
| rbasak | If you want the suggestion to be read by someone who is in a position to act on it, it might be better to file a "Wishlist" bug against the relevant package. | 13:15 |
| Riddell | didrocks: any news on bluez 5? | 13:30 |
| Riddell | pitti: any news on systemd transition? | 13:31 |
| didrocks | Riddell: syncing with the Touch team is today (in a couple of hours), will keep you posted | 13:31 |
| didrocks | Riddell: the desktop-side is almost fully ready, won't block anyway | 13:31 |
| pitti | Riddell: still blocked on fixing bug 1312976 (slangasek), and updating juju and maas :( | 13:36 |
| ubottu | bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312976 | 13:36 |
| seb128 | slangasek said he would have his bits done previous week, not sure what's going on with that :-/ | 13:39 |
| Riddell | pitti: thanks, do you expect that this cycle? (feature freeze being next week) | 13:40 |
| didrocks | Riddell: this week, rather? (not on Thursday?) | 13:40 |
| Riddell | didrocks: good point | 13:41 |
| === Guest33360 is now known as rcj | ||
| === rcj is now known as Guest49948 | ||
| === pgraner-hol is now known as pgraner | ||
| pitti | Riddell: we know that juju will only release in March, but we could work around that by booting juju generated instances with upstart; as for NFS, I don't know -- I hope so | 13:52 |
| pitti | Riddell: at that point we probably should have a meeting with the foundations team, to discuss the next steps | 13:53 |
| mdeslaur | pitti: also need apparmor support before it can be default...ask tyhicks when that's planned | 13:54 |
| pitti | mdeslaur: oh? that's news to me; from my POV that has worked for months, what's missing? | 13:55 |
| === josepht_ is now known as josepht | ||
| mdeslaur | pitti: it needs to load the apparmor policy at boot like it does with selinux, smack, etc. | 13:55 |
| mdeslaur | it currently doesn't | 13:55 |
| mdeslaur | it uses an init script which loads policy after services have started (ie: too late) | 13:55 |
| pitti | it's in rcS, so started very early | 13:56 |
| mdeslaur | pitti: does boot wait for it to complete before starting other services, or can apache be started before it? | 13:56 |
| pitti | so it sounds like we merely need to make sysinit.target block on this? | 13:56 |
| pitti | mdeslaur: apache can't | 13:56 |
| mdeslaur | pitti: well, the real solution is to fix it properly :) | 13:57 |
| pitti | Before=sysinit.target | 13:57 |
| pitti | that's what will ensure that apparmor starts in very early boot, before any real service | 13:57 |
| pitti | mdeslaur: well, in my POV that *is* properly working | 13:57 |
| mdeslaur | pitti: before network devices come up? | 13:57 |
| pitti | mdeslaur: before NM and /etc/init.d/networking, but we can make that stronger (make network-pre.target come after apparmor) | 13:59 |
| pitti | mdeslaur: so, there's no bug or work item for this, do you have a list of those concerns? | 13:59 |
| mdeslaur | pitti: ideally, we should load in src/core/main.c at the name place where selinux and smack get done | 13:59 |
| pitti | mdeslaur: yeah, certainly sounds faster than having to call an init.d script; but I thought that was mostly optimization | 13:59 |
| mdeslaur | sure, there are work items, hold on | 14:00 |
| mdeslaur | pitti: we kept getting races with it being a script in upstart, which is why we want it to be at boot in systemd...but this requires using a pre-compiled apparmor policy at boot so as not to hang for a couple of minutes...this exists, but hasn't been uploaded to vivid yet | 14:02 |
| mdeslaur | pitti: that's why every there are apparmor bits sprinkled all over the upstart jobs :P | 14:02 |
| pitti | mdeslaur: so, I'm happy to add a network-pre ordering for apparmor; services already come after sysinit.target (which apparmor is part of), just network devices have a separate dependency tree | 14:04 |
| pitti | mdeslaur: ah no, I lie -- network-pre.target already comes after sysinit.target, so it's all good | 14:04 |
| * pitti missed the DefaultDependencies=yes | 14:04 | |
| mdeslaur | pitti: tyhicks can take a look with you when he gets here | 14:05 |
| pitti | so the only things that run without apparmor are mounting local and virtual file systems, swaps, cryptsetup unlock, starting udevd | 14:05 |
| mdeslaur | except we'll hang boot while policy is being compiled | 14:06 |
| pitti | and they are all needed to allow running apparmor or even getting enough of your file system, so nothing can't really run even earlier | 14:06 |
| pitti | mdeslaur: on first boot, you mean? | 14:06 |
| mdeslaur | every kernel update | 14:07 |
| pitti | mdeslaur: how is that different under upstart? | 14:07 |
| pitti | I mean, if we have a dpkg trigger to update the cache for a new kernel, that should apply to any init system? | 14:07 |
| pitti | (or a kernel/postinst.d script) | 14:08 |
| mdeslaur | in upstart, we've sprinkled apparmor policy in the different upstart jobs so only a few profiles get compiled during the boot process, the others are handled by the init script later on while the system is coming up | 14:08 |
| pitti | mdeslaur: ah, so isn't that essentially the same then? | 14:08 |
| mdeslaur | pitti: well, we _could_ defer the init script later on, and then sprinkle apparmor bits in a bunch of systemd units | 14:09 |
| mdeslaur | but that's...ugh. | 14:09 |
| pitti | mdeslaur: (don't get me wrong: if we can make it faster, let's -- but before that I'm interested in making it work correctly) | 14:09 |
| ochosi | didrocks: since it just got uploaded to NEW (by Mirv) and we need an archive admin to approve (before FF), do you have a minute to take a look at this? https://bugs.launchpad.net/lightdm-gtk-greeter-settings/+bug/1295405 | 14:10 |
| ubottu | Launchpad bug 1295405 in Settings editor for LightDM GTK+ Greeter "[needs-packaging] Package and upload to vivid" [Wishlist,In progress] | 14:10 |
| mdeslaur | we're pretty much ready with the ideal situation...the apparmor code to cache is written, just needs to be uploaded to vivid | 14:10 |
| mdeslaur | at which point, the systemd patch is pretty trivial to load it at boot | 14:10 |
| didrocks | ochosi: will do later today and keep you posted | 14:10 |
| mdeslaur | and then we can add the postinst triggers to the kernel packages | 14:10 |
| ochosi | didrocks: thanks a lot, it's much appreciated! | 14:11 |
| didrocks | yw! :) | 14:11 |
| mdeslaur | tyhicks: please discuss apparmor plans with pitti when you get here | 14:12 |
| pitti | mdeslaur: ack, thanks for the heads-up! | 14:12 |
| pitti | mdeslaur: so, the summary from this conversation for me is: it currently works correctly, but slow, and we have a "pre-build cache" in the works to avoid recompiling the policy at boot | 14:13 |
| pitti | mdeslaur: does that sound right to you? | 14:13 |
| mdeslaur | pitti: I don't know if it works correctly, someone needs to check. Based on your statement that it loads early in the process, it's plausible. | 14:14 |
| mdeslaur | if it does work correctly with no races, then it's ok for vivid as-is | 14:15 |
| mdeslaur | (my opinion) | 14:15 |
| === marcusto_ is now known as marcustomlinson | ||
| pitti | mdeslaur: *nod*; yeah, I'm fairly convinced that it runs just about as early as it could, and it can't plausibly run earlier | 14:16 |
| pitti | mdeslaur: the one thing that potentially could move after it is udev, if we have an apparmor profile for udev | 14:16 |
| pitti | everything else seems okay | 14:16 |
| pitti | but given how udev rules are pretty much almighty, it doesn't seem to make much sense to try and confine it | 14:17 |
| pitti | upstream runs udevd in its own mount namespace, but we have some bits that rely on that it doesn't | 14:17 |
| mdeslaur | I don't care about confining udev...just about how udev handles having network devices pop up, for example | 14:18 |
| mdeslaur | but I gather it waits for NM | 14:18 |
| pitti | mdeslaur: right, that's already sorted; apparmor runs before sysinit.target which is a dependency of network-pre.target, and everything regarding network conf depends on that | 14:18 |
| pitti | (both statically from /etc/network/interfaces and dynamically via ifup@.service, i. e. udev events) | 14:19 |
| pitti | (FTR, network-pre.target is the place where firewalls and the like should hook into -- to run before the first interface is brought up) | 14:20 |
| hallyn | pitti: thanks! | 14:20 |
| mdeslaur | pitti: ok, so if it starts before networking, should be ok | 14:21 |
| mdeslaur | good thing vivid isn't an LTS :P | 14:21 |
| pitti | mdeslaur: heh, yes; we wouldn't swap out init in an LTS.. | 14:22 |
| mdeslaur | ;P | 14:22 |
| pitti | then again, my doubts whether we'll actually switch in vivid are relatively high now, given how long the three last items have dragged on | 14:22 |
| pitti | Riddell: are you asking just for personal interest, or does Kubuntu actually require/work better with systemd? | 14:23 |
| mdeslaur | pitti: so you have a workaround for juju...what are the other two? nfs? does that mean nfs isn't currently handled in debian? | 14:26 |
| Riddell | pitti: Plasma developers say they'll requre it from the end of this year, so no rush there. and I was wondering if we'll need to worry about it for beta 1 or otherwise test this cycle | 14:26 |
| pitti | mdeslaur: Debian uses NFS's init.d script; but our's is split into several upstart jobs, which slangasek wanted to keep; he said he'd rather do that himself | 14:27 |
| mdeslaur | pitti: oh, I see | 14:28 |
| pitti | Riddell: hm, I had expected KDE (or GNOME etc.) to rather use session systemd, and not really care about the system init? | 14:28 |
| Riddell | pitti: yes of course, but aren't they related somewhat? | 14:29 |
| pitti | Riddell: you need system systemd in order to run session systemd (I guess) | 14:39 |
| pitti | but so far we are still using upstart for sessions | 14:39 |
| === marcusto_ is now known as marcustomlinson | ||
| tyhicks | pitti, mdeslaur: re apparmor changes> We're (upstream apparmor) currently discussing the libapparmor API changes to allow systemd to load apparmor policy cache files | 14:52 |
| tyhicks | pitti, mdeslaur: v1 of that patchset is written and works great, but there are changes that need to be made to the API | 14:53 |
| tyhicks | pitti, mdeslaur: After that lands, we need to add one more feature (support multiple apparmor policy caches) and then update kernel postinit script to generate a policy cache after installation | 14:54 |
| tyhicks | pitti, mdeslaur: So, we're still a ways away from landing everything | 14:54 |
| tyhicks | pitti, mdeslaur: But, jdstrand seemed to think that the init script is sufficient for now. (We all acknowledge that we want systemd to be able to do its own policy cache loads ASAP) | 14:55 |
| tyhicks | pitti, mdeslaur: I haven't had a chance to look at the init script but what pitti said about it above is promising | 14:56 |
| pitti | tyhicks: thanks for the update! | 15:05 |
| pitti | tyhicks: right, that seems to confirm the "it works correctly but slowly" status quo, and how we'll improve it | 15:06 |
| === sil2100_ is now known as sil2100 | ||
| LocutusOfBorg1 | hi, can anybody please sync virtualbox/guest additions from debian/experimental? | 15:44 |
| LocutusOfBorg1 | bug 1422134 | 15:44 |
| ubottu | bug 1422134 in virtualbox-guest-additions-iso (Ubuntu) "please sync virtualbox from debian experimental" [Undecided,New] https://launchpad.net/bugs/1422134 | 15:44 |
| caribou | is there any issue with package synchronization from Debian (experimental especially) ? | 15:59 |
| caribou | I uploaded makedumpfile to experimental end of last week and it's still at the previous version in Vivid ? | 15:59 |
| caribou | should I sync manually ? | 16:00 |
| dobey | caribou: i think it's no longer auto sync after alpha or something like that perhaps? | 16:06 |
| dobey | caribou: also did your change make it to unstable? i don't recall if we sync from experimental or unstable, but i think the latter | 16:07 |
| caribou | dobey: no, unstable is frozen awaiting Jessie's release | 16:07 |
| dobey | ah | 16:08 |
| mitya57 | pitti: Can you please look what happened to paramiko autopkgtest? The trace indicates that python(3)-crypto is not installed, however it should be pulled in via dependencies. | 16:08 |
| caribou | dobey: but that's fine, I can sync manually I just wanted to be sure of the process | 16:08 |
| didrocks | ochosi: accepted (building now) | 16:37 |
| mdeslaur | infinity, slangasek, kees, stgraber: meeting? | 17:01 |
| infinity | Oh, err. Yes. One of those. | 17:02 |
| jdstrand | tyhicks (and pitti and mdeslaur): re apparmor init script as sufficient> I was speaking for Ubuntu Core and snappy apps. I don't know about system policy we ship in traditional desktop/server. that said, it sounds like pitti said it should be ok there too, so I guess I'm 'ok' with not landing it, but if systemd is pid 1 on the phone, the speed improvement would be quite good | 17:18 |
| tyhicks | jdstrand, pitti, mdeslaur: I think we can land, in lp:apparmor, the changes needed for systemd to do policy loading in 1-2 weeks | 17:29 |
| jdstrand | cool, let's continue to shoot for that | 17:50 |
| cjwatson | caribou: We never auto-sync from experimental. | 18:03 |
| cjwatson | dobey: import freeze is Thursday | 18:03 |
| dobey | ah ok | 18:04 |
| melodie | hi | 19:06 |
| === danjared_ is now known as danjared | ||
| melodie | I would like to know what function the 3 following packages have: "libc-dev-bin", "libc6-dev:<arch>", "linux-libc-dev:<arch>", because they are in Ubuntu, they used to be in Lubuntu, when I made a custom version and didn't have them, the live iso booted to the login screen instead of booting to the desktop. What exactly is their function? | 19:09 |
| melodie | I have had this question in mind for a real long time, and never had an opportunity to ask. now would be the time. :) | 19:10 |
| melodie | especially as I have never seen them in the "ubuntu-standard" nor in the "ubuntu-minimal" packages... | 19:10 |
| melodie | if anyone has a clue? | 19:17 |
| dobey | apt-cache policy $package didn't answer it for you? | 19:20 |
| melodie | I can see two of them come from the eglibc source, and linux-libc-dev is related to kernel headers. | 19:32 |
| melodie | dobey if it's not in Lubuntu apt-cache policy would not answer. I was looking in the Ubuntu packages | 19:33 |
| melodie | is there a command line which will say which package could possibly pull them in the flavors where they exist? | 19:33 |
| dobey | err, not policy | 19:34 |
| dobey | i meant apt-cache show | 19:34 |
| dobey | seeded-in-ubuntu tells you where packages are seeded (if they are) | 19:34 |
| dobey | apt-cache rdepends will show you what packages depend on them | 19:34 |
| === roadmr is now known as roadmr_afk | ||
| melodie | dobey I look thanks. I will perhaps try to read through eventual comments if any, in the sources | 19:57 |
| melodie | dobey seeded-in-ubuntu brought me nothing because the packages I seek info are not "primary" packages, but rdepends says things. quite funny actually | 20:28 |
| === roadmr_afk is now known as roadmr | ||
| melodie | there are many reverse depends for each, what I notice is "libc6-dev" has one rdepends on "linux-libc-dev", and "linux-libc-dev" is also pulled in by "libc6-dev". (Several times in the list). | 20:29 |
| melodie | isn't that strange? | 20:29 |
| melodie | dobey I still don't know all the features they bring but I might have found why they are not in lubuntu | 20:45 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === pgraner is now known as pgraner-afk | ||
| jdstrand | sbeattie, tyhicks: hey, I had a question about apparmor 2.9 and ff | 21:20 |
| tyhicks | hi | 21:20 |
| jdstrand | sbeattie, tyhicks: this is prompted by two things: a) there is an apparmor 2.9 in the security proposed ppa, and b) bug #1422521 | 21:20 |
| ubottu | bug 1422521 in apparmor (Ubuntu) "mmap of ...mir/client-platform/mesa.so DENIED" [Undecided,Triaged] https://launchpad.net/bugs/1422521 | 21:20 |
| jdstrand | sbeattie: does 2.9 introduce features over 2.8.98-0ubuntu4? | 21:21 |
| === salem_ is now known as _salem | ||
| sbeattie | jdstrand: no, everything has been purely bug fixes in the polishing for the 2.9.0 and 2.9.1 releases. | 21:22 |
| sbeattie | (well, there are minor things like supporting the generation of coverage information in the utils/ tests) | 21:25 |
| sbeattie | but there should be no user visible features added between 2.8.98 and 2.9.1 | 21:25 |
| sbeattie | jdstrand: ^ | 21:26 |
| jdstrand | tyhicks, sbeattie: with that in mind, is there any urgency in getting 2.9 into vivid this week? it sounds like 1422521 is causing problems at least on the nexus 5 | 21:26 |
| jdstrand | and it we fixed that, it seems we would want to update to 2.9... | 21:26 |
| jjohansen | more urgent than ecryptfs or systemd changes? | 21:26 |
| jdstrand | well, I was thinking sbeattie would do it, and he isn't working on those as much, but certainly that is a consideration | 21:27 |
| jdstrand | (to be clear, no I don't think more urgent than those) | 21:27 |
| sbeattie | jdstrand: I'd been meaning to push 2.9 in to vivid for a while, but had gotten pre-empted by other priorities. | 21:28 |
| jdstrand | right, hence the question here :) | 21:29 |
| jdstrand | should it continue to be preempted or should it get uploaded | 21:29 |
| jdstrand | tyhicks: thoughts? ^ | 21:29 |
| sbeattie | I ran the packages through qrt at one point, and I'm running them on my laptop, so I'm pretty confident in them. | 21:29 |
| tyhicks | sorry, got distracted in another channel | 21:30 |
| * tyhicks reads backscroll | 21:30 | |
| jdstrand | sbeattie: is what is in the ppa what you would want to push? | 21:31 |
| jdstrand | (aforementioned bug aside) | 21:31 |
| sbeattie | jdstrand: there are some minor fixes, mostly policy touchups, awaiting a 2.9.2 release. | 21:34 |
| sbeattie | ... that have already been committed to the upstream 2.9.x branch. | 21:34 |
| sbeattie | But I'd kind of like the gcc-5 issue to reach a statis point before releasing 2.9.2. | 21:35 |
| tyhicks | sbeattie: how much work is it to cut 2.9.2, package, and test it? | 21:36 |
| sbeattie | That said, we could come back with a 2.9.2 after FF, as it shouldn't have anything but bugfixes as well (other than what's needed for systemd support) | 21:36 |
| sbeattie | tyhicks: not much, a day. | 21:36 |
| * jdstrand notes https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor | 21:37 | |
| tyhicks | is 2.9.1 ready to push to vivid today? | 21:37 |
| tyhicks | right - the test plan adds a bit to it | 21:37 |
| jdstrand | tyhicks: we would need to run the test plan | 21:37 |
| jdstrand | aiui | 21:37 |
| sbeattie | okay, the test plan would take longer, as I haven't run through that before. | 21:38 |
| jdstrand | it could be split up | 21:38 |
| jdstrand | eg, I have a spare device I could do the touch testing on | 21:38 |
| jdstrand | so the question is, test what we have and wait for 2.9.2 and upload that later, or wait for 2.9.2. I'm guesing systemd would be after that | 21:39 |
| tyhicks | so if we get the gcc 5 fixes upstream today, cut a release tomorrow, and then test and upload on thursday, we could do 2.9.2 | 21:39 |
| tyhicks | jdstrand: systemd is definitely after that | 21:40 |
| jdstrand | I don't think we need heroics for the ff since this isn't a ffe | 21:40 |
| jdstrand | (since now I know it is just bug fix) | 21:40 |
| jdstrand | so no it is simply is now a good time for sbeattie to do it or not | 21:41 |
| jdstrand | now* | 21:41 |
| tyhicks | sbeattie: what's your feeling? | 21:42 |
| tyhicks | I'd assume that he's going to eventually cut 2.9.2 no matter what | 21:42 |
| sbeattie | Yeah. | 21:43 |
| tyhicks | but you're right, there's no need to rush around right before FF for a bug fix release | 21:43 |
| sbeattie | I'd kind of like to get it in, as I imagine it would make the FFe for the systemd changes go easier if there aren't unrelated changes to go along with it. | 21:43 |
| jdstrand | that said, we may not want to make 1422521 wait too long | 21:44 |
| sbeattie | right. | 21:44 |
| * tyhicks looks at the gcc 5 issues to get a feel for how long that'll take | 21:44 | |
| jdstrand | sbeattie: are you thinking 2.9.2 upstream will be ready some time this week? | 21:44 |
| jdstrand | sbeattie: also, can I assign 1422521 to you? | 21:45 |
| sbeattie | yeah, I was thinking that making sure the parser compiles under gcc-5 was worthy of cutting a release. | 21:45 |
| sbeattie | (as I'm not sure of other downstreams timeframes for incorporating gcc-5) | 21:45 |
| sbeattie | jdstrand: 1422521> sure. | 21:46 |
| jdstrand | sbeattie: done (thanks) | 21:46 |
| sbeattie | tyhicks: re 2.9.1 readiness> it's packaged and sitting in the sec-proposed-ppa, it could go after testing and incorporating the fix for 1422521. | 21:47 |
| tyhicks | right | 21:47 |
| tyhicks | sbeattie, jdstrand: lets go with 2.9.1 + the 1422521 fix | 21:48 |
| tyhicks | sbeattie, jdstrand: no need to stress ourselves out for 2.9.2 | 21:49 |
| sbeattie | tyhicks: okay, that works. | 21:49 |
| * jdstrand prepares spare device | 21:49 | |
| chiluk | did someone finally fix the lockscreen lockup problem? I haven't had my desktop lockup in a few days now. | 21:49 |
| melodie | good night | 22:46 |
| arges | hallyn: around? | 23:03 |
| zacthespack | Hello, out of interest how are the Ubuntu core rootfs generated? there are many build tools about but im interested in the best method to replicate a Ubuntu core rootfs from source | 23:04 |
| zacthespack | if anyone has the info please drop me a PM or email: zacthespack@gmail.com | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!