| === lifeless_ is now known as lifeless | ||
| === maclin1 is now known as maclin | ||
| === salem_ is now known as _salem | ||
| === mwhudson_ is now known as mwhudson | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
| seb128 | mardy, hey, did you see https://errors.ubuntu.com/problem/c3cf712b54fe02d52c758702cb8176ea0cbcc916 ? seems a new signon-ui error in zesty and quite high on the e.u.c reports | 10:13 |
|---|---|---|
| seb128 | mardy, https://errors.ubuntu.com/problem/0fdd752751a7b257fd4c7adaa057bd536ff767ce as well | 10:14 |
| mardy | seb128: hi! Yes, it's https://bileto.ubuntu.com/#/ticket/2608 | 10:14 |
| seb128 | mardy, great, thanks! | 10:14 |
| fossfreedom_ | jbicha: re UG Try/Installl decorations missing - we had a similar issue http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6517 | 10:20 |
| fossfreedom_ | I think the key part was the addition of the X11 environment variable on line 508 | 10:21 |
| LocutusOfBorg | camako, can you please make boost1.62 available for mir? | 10:36 |
| LocutusOfBorg | http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html | 10:37 |
| LocutusOfBorg | it has some hard-coded runtime deps I guess, I think you just need to bump them :) | 10:37 |
| mapreri | /cc alan_g ↑ | 11:03 |
| mapreri | (mostly solved between #ubuntu-mir and #ubuntu-release anyway) | 11:04 |
| jbicha | fossfreedom_: thanks, do you happen to know how I could test whether that fixes my bug? | 11:18 |
| fossfreedom_ | jbicha: not easily - I had to build an ISO using our ISO builder - had to hack the Try/Install screen to launch a terminal session to then allow me to experiment. There must be an easier way to debug changes to ubiquity - I'm not aware of how though :( | 11:21 |
| jbicha | I'll ask on #ubuntu-installer | 11:23 |
| jbicha | maybe I'd have to make a persistent live USB? | 11:24 |
| fossfreedom_ | possibly - that is an area I had not tried. we'll worth having a go | 11:26 |
| === _salem is now known as salem_ | ||
| jbicha | fossfreedom_: your fix worked, see my update on LP: #1675210 | 12:39 |
| ubottu | Launchpad bug 1675210 in ubiquity (Ubuntu) "Ubuntu GNOME 17.04 Try or Install screen missing decorations" [Undecided,New] https://launchpad.net/bugs/1675210 | 12:39 |
| fossfreedom_ | jbicha: \o/ :-) | 12:39 |
| exp-innit | a question i originally asked in #ubuntu, is anyone aware of the procedures used to prepare the netinstall iso? i need to customise its kernel somewhat and the default one is missing some modules and potentially firmware. I could not find any documentation on the release preparation process or anything like that | 13:16 |
| mdeslaur | exp-innit: the scripts are here https://code.launchpad.net/~ubuntu-cdimage | 13:19 |
| mdeslaur | exp-innit: that's all I know | 13:19 |
| exp-innit | mdeslaur: hmm, this does look pretty close, but i don't see an explicit mention of netinst, i'll keep looking :) | 13:22 |
| === spineau is now known as spineau_afk | ||
| exp-innit | mdeslaur: i'm not even sure which script to be using here, but they seem to depend on livefs-builders for which i can find no authoritative source | 13:51 |
| exp-innit | and these seem to be focused on live, not net images, although that may be a different issue | 13:51 |
| exp-innit | any suggestions? | 13:51 |
| mdeslaur | exp-innit: no, sorry, that repo is all I know about | 13:53 |
| exp-innit | mdeslaur: i see, well thanks for the link, it gets me closer :) | 13:53 |
| brendand | is it no longer possible to test against multiple packages built from source using autopkgtest? | 14:11 |
| brendand | "autopkgtest: error: You must specify only one source package to test" | 14:11 |
| exp-innit | so from what i can tell, this livefs-builders seems to be a configuration file present somewhere on launchpad, there's a group of users allowed to use it, but i have no idea where it actually resides or how to utilise it locally | 14:41 |
| exp-innit | advice very welcome! | 14:41 |
| === JanC_ is now known as JanC | ||
| nacc | brendand: not sure i understand? the tests live in some specific source package? | 15:06 |
| brendand | nacc, there used to be an --unbuilt-tree option to build from source | 15:13 |
| brendand | nacc, that seems to have been replaced by just specifying the path as an argument, but you could define multiple --unbuilt-tree's | 15:13 |
| brendand | not so now it seems | 15:14 |
| nacc | brendand: right, you are testing one source package -- i'm not sure i follow the use case? | 15:15 |
| nacc | brendand: you can specify dependencies on the command-line, but as binary packages | 15:15 |
| nacc | brendand: you can pass a singe unbuilt source package as the argument, as well | 15:15 |
| brendand | nacc, yeah it's to use a dependency built from source | 15:16 |
| nacc | brendand: ah, yeah, either build that locally first or use a PPA | 15:16 |
| nacc | slangasek: did the process-components-mismatch emailer get broken recently? | 15:48 |
| nacc | slangasek: it now says the following packges.... MIR: #1667003 (Confirmed) | 15:48 |
| nacc | slangasek: and doesn't list the package :) | 15:48 |
| jgrimm | nacc, able to take a sponsorship -> https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1634989 | 15:51 |
| ubottu | Launchpad bug 1634989 in rabbitmq-server (Ubuntu Yakkety) "Segfault on rabbitmq-server start" [Undecided,In progress] | 15:51 |
| nacc | jgrimm: ack | 15:52 |
| jgrimm | cool, thanks sir | 15:52 |
| slangasek | nacc: it's always been broken, it does weird diffing | 15:56 |
| nacc | slangasek: ah ok, i thought i saw a bug # before, i'll assume i was wrong :) | 16:04 |
| slangasek | nacc: when there is no change to the list of packages that are component-mismatched, but there's a change in the MIR bug state, it sends the weird contextless mail | 16:05 |
| nacc | slangasek: ah got it | 16:06 |
| exp-innit | don't suppose either of you know the answer to my question above? :) | 16:11 |
| nacc | exp-innit: sorry, missed the question on reboot, possibly? | 16:14 |
| exp-innit | nacc: i'm looking for how the netinst isos for ubuntu are produced so i can customise them | 16:17 |
| exp-innit | i was linked to https://code.launchpad.net/~ubuntu-cdimage but these seem to be backed by configuration settings i don't have access to, such as a 'livefs-builders' file | 16:20 |
| infinity | exp-innit: By "netinst ISOs", do you mean the mini.iso? | 16:36 |
| infinity | exp-innit: Because that's just "apt-get source debian-installer", it has nothing to do with cdimage. | 16:36 |
| exp-innit | infinity: i see | 16:38 |
| infinity | exp-innit: As for the other question, unless you're locally running launchpad, livefs-builders will be useless to you. You need to look at the spirit of the code, not the literal implementation (ie: that cdimage asks some remote machine/process to build a livefs, which you might have to do by hand instead using live-build, then it downloads the result and does things to it) | 16:38 |
| infinity | exp-innit: But yes, if all you're interested in is the tiny netinst mini.iso, none of the cdimage infra is interesting, that's produced by the debian-installer package build. | 16:39 |
| exp-innit | infinity: i see, the 'spirit of the code' is rather a waste of time though isn't it? i mean even if that's what was intended | 16:40 |
| infinity | exp-innit: What's a waste of time? | 16:41 |
| exp-innit | infinity: if there's a bunch of repositories available where their dependencies are not | 16:42 |
| exp-innit | ie the livefs-builders stuff | 16:42 |
| exp-innit | or are they actually available somewhere that i missed? | 16:42 |
| exp-innit | because the entries on google are minimal to say the least | 16:42 |
| infinity | exp-innit: The dependency totally exists. It's called "run your own launchpad". If you mean we should include a sample version of the file that effectively says that, sure, maybe. | 16:42 |
| exp-innit | infinity: if it's intrinsically tied to launchpad i can't quite understand why, but it would at least be nice to mention it | 16:43 |
| infinity | exp-innit: Well, it's tied to either LP or a remote builder running our old buildd setup. livefs-builders defines one, lives-launchpad defines the other. It could certainly be modified to call a live-build/livecd-rootfs wrapper locally, but that's not a use-case we've needed. | 16:45 |
| infinity | exp-innit: The point of releasing the code is to let people grab bits they want, see how we do things and, sure, run it if they feel the urge, but I'd hardly call it a product we support. | 16:45 |
| exp-innit | infinity: being able to rebuild the installer is a fairly important thing imho, the mini iso aside as you've given me all the information i require there | 16:46 |
| exp-innit | would you not say the installer is a product you support? | 16:46 |
| exp-innit | or, do the cdimage repositories count as a slightly different category? | 16:46 |
| exp-innit | (needless to say, i have not been able to find documentation to elucidate on these topics) | 16:46 |
| davmor2 | exp-innit: if all you are trying to do is modify your own cd use the dell product it is designed to do exactly that | 16:47 |
| infinity | exp-innit: We support the ISOs we product. We certainly don't support people altering them. In fact, we go out of our way to NOT support that. :) | 16:47 |
| infinity | s/product/produce/ | 16:48 |
| exp-innit | davmor2: the dell product? | 16:48 |
| exp-innit | infinity: i don't know what to say to that, that's a rather bizarre approach | 16:48 |
| exp-innit | ubuntu may only be installed the official way? | 16:48 |
| exp-innit | i require a custom kernel module, so i should not use ubuntu? | 16:48 |
| davmor2 | exp-innit: just looking for the app name | 16:49 |
| infinity | exp-innit: How does a custom kernel module require a new ISO? But no, I'm not saying you shouldn't use Ubuntu. I'm saying we don't *support* building custom ISOs. We support Ubuntu, and the media we produce to install it. A subtle difference, maybe. | 16:49 |
| davmor2 | exp-innit: but there is a nice guide here https://help.ubuntu.com/community/LiveCDCustomization | 16:50 |
| infinity | We release the tools. They're out there. But the goal of them isn't to make them flexible and usable in environments other than ours. | 16:50 |
| exp-innit | infinity: how does it not require a new ISO if the ISOs produced are one-size-fits-all-do-not-modify? | 16:51 |
| exp-innit | and davmor2 i believe one of the steps there is "download an official iso, then hack on it!" | 16:51 |
| exp-innit | which is not really the sort of solution we were hoping to aim for | 16:51 |
| exp-innit | anyhow, the mini.iso approach should be fine | 16:51 |
| exp-innit | but i must say i find the approach confusing | 16:51 |
| davmor2 | exp-innit: the ubuntu iso is a fixed thing it should only be release by Ubuntu and be checkable how can that be the case if it is modifiable | 16:52 |
| davmor2 | exp-innit: it would be like buying a music cd then complaining that you can't add your track too it | 16:53 |
| exp-innit | davmor2: no it would be like downloading a deb then complaining that i can't get the corresponding src package | 16:53 |
| infinity | exp-innit: The source is all there. So no, it's not like that. | 16:53 |
| exp-innit | infinity: other than the required parts to do the buildpackage step, which is what i started asking about really | 16:54 |
| exp-innit | anyhow, this is going nowhere, and i have no intention on arguing the point | 16:54 |
| exp-innit | the answer you gave re: mini.iso should be more than sufficient | 16:54 |
| infinity | exp-innit: However, we do have a trademark policy that says you can't build your own Ubuntu distribution and call it Ubuntu. | 16:54 |
| infinity | For reasons that should be self-evident. | 16:54 |
| exp-innit | infinity: that is completely irrelevant? | 16:55 |
| infinity | exp-innit: Depends. Are you distributing these modified ISOs? If so, then it's really not irrelevant. | 16:55 |
| exp-innit | infinity: if i was, that would be a matter for your legal department | 16:55 |
| infinity | (Unless you're also calling them expLinux (based on Ubuntu)) | 16:55 |
| infinity | exp-innit: Anyhow, your complaint originally of a missing config file is hardly "the source code is missing". And the content of the config file could be determined by a quick glance at the source. The larger blocker there, as I pointed out, is what the config file actually defines the other end to be. | 16:56 |
| exp-innit | i don't see how this has any bearing whatsoever, unless you're saying Ubuntu doesn't support customising the install ISOs because they wish to enforce their copyright on the word "Ubuntu" | 16:56 |
| bdmurray | What does blacklisted mean? http://autopkgtest.ubuntu.com/packages/a/akonadi/xenial/s390x | 16:56 |
| infinity | exp-innit: And saying "I don't want to run launchpad" isn't the same as "you don't release the source". | 16:56 |
| exp-innit | infinity: the contents are not as divinable as you believe, and i didn't refuse to run launchpad, it is undocumented (or poorly documented) that that is the case | 16:57 |
| davmor2 | exp-innit: Ubuntu Customization Kit is the dell tool. | 16:58 |
| infinity | exp-innit: http://paste.ubuntu.com/24235823/ | 16:59 |
| exp-innit | davmor2: thank you, i'm not sure it really fits our needs but i appreciate you looking it up and letting me know, i'll certainly look through it | 16:59 |
| infinity | exp-innit: There's no secret sauce in those files, they're just literally useless outside our production environment. But that's what they look like. | 16:59 |
| Laney | bdmurray: That the infrastructure won't run it | 16:59 |
| Laney | no I don't know who put akonadi there, or why | 17:00 |
| exp-innit | infinity: i see, well can i suggest that some documentation be added at least somewhere that explicitly warns people off this approach? | 17:00 |
| exp-innit | as it certainly violates the principle of least surprise that the ISOs are only customisable after their construction | 17:01 |
| exp-innit | that is somewhat the opposite of every linux system i can think of, and i don't mean that as an insult | 17:01 |
| infinity | exp-innit: Is it? It's never been easy to reproduce the Debian ISO infrastructure either. | 17:04 |
| infinity | We may have accidentally made it more complicated when we forked it 13 years ago, but... | 17:04 |
| exp-innit | infinity: i can't think of any other example where the policy is that you should modify the built 'binary' package, rather than modify the source of it | 17:05 |
| exp-innit | the difficulty of the infrastructure wasn't really my point | 17:05 |
| infinity | exp-innit: Err, no. We have no policy that implies that either. | 17:05 |
| exp-innit | i'm just saying, the policy is surprising, and should be noted somewhere, at least somewhere more prominent as i was not able to find it | 17:05 |
| infinity | exp-innit: The policy is that you can't modify it *and* redistribute it under the name Ubuntu. | 17:06 |
| exp-innit | infinity: isn't that literally a wiki page linked before? | 17:06 |
| exp-innit | https://help.ubuntu.com/community/LiveCDCustomization ? | 17:06 |
| infinity | exp-innit: Whether you modify at build time or post-build, there's no "policy" around that, just common sense that reproducing our build infra is harder than mangling an ISO. | 17:06 |
| exp-innit | ok, well semantic arguments about "policy" aside | 17:06 |
| exp-innit | it would be nice if there was some explicit warning | 17:07 |
| exp-innit | as a related question, but wholly from the opposite perspective, we've noticed there are modules available in the -generic kernel packages that are not available in the installer by default, is there documentation as to the extent of what's included or not? | 17:11 |
| infinity | exp-innit: By "in the installer", you mean in d-i installs? Cause it should all be available in desktop installs. | 17:12 |
| infinity | exp-innit: For d-i installs, it's self-documenting via the debian-installer source (which defines which udebs are built into which targets) and the linux source (which defines which modules are in which udebs). | 17:12 |
| exp-innit | infinity: unfortunately i did not author the install environment here, but i believe it's based off netboot or the mini iso | 17:13 |
| exp-innit | but, that answer is perfectly sufficient, thanks | 17:13 |
| davmor2 | exp-innit: there is only one generic kernel, during the install you have the option to enable 3rd party drivers which will either pull from the iso or from the web if you are connected, but those modules can not be shipped by default because it is not allowed by the companies owning the rights to those packages | 17:14 |
| exp-innit | davmor2: i don't think these are license restricted packages, but they may be firmware associated or so, i will need to investigate a little further | 17:15 |
| exp-innit | thanks for the answer though, much appreciated | 17:15 |
| infinity | slangasek, bdmurray: You both have a bunch of commits on livecd-rootfs trunk. Are those good to be pushed to the archive? | 17:36 |
| slangasek | infinity: yes | 17:37 |
| slangasek | (didn't I already? sorry) | 17:37 |
| infinity | slangasek: Nope. And my RPi fix on trunk that I assumed someone would release by now never made it in. ;) | 17:37 |
| infinity | (Obviously my fault, not yours, but...) | 17:37 |
| slangasek | yeah, mine are all good to release but also not urgent | 17:37 |
| infinity | The RPi fix is only urgent if I recide to respin that image before I release the beta. | 17:38 |
| infinity | Which I suppose I could do quickly. | 17:38 |
| infinity | If we upload livecd-rootfs and push it through. | 17:38 |
| infinity | Objections? | 17:38 |
| slangasek | no objection here | 17:39 |
| bdmurray | none | 17:40 |
| infinity | xnox: *poke* | 17:51 |
| infinity | xnox: Around? | 17:51 |
| infinity | slangasek: Or, wait, is xnox here this week? | 17:51 |
| slangasek | infinity: he is not | 17:51 |
| infinity | Bah. | 17:51 |
| infinity | Is there anyone else who has a clue how to "test" the s390x server ISO? | 17:52 |
| slangasek | infinity: something I can xnox for you? | 17:52 |
| slangasek | ah | 17:52 |
| slangasek | powersj: ^^ ? | 17:52 |
| infinity | dannf: You around? | 17:52 |
| dannf | infinity: yup | 17:52 |
| infinity | dannf: Can I get a (very) quick boot/install/reboot smoketest of zesty beta2 arm64? | 17:53 |
| infinity | dannf: http://cdimage.ubuntu.com/ubuntu-server/daily/20170321/zesty-server-arm64.iso | 17:53 |
| dannf | infinity: sure | 17:53 |
| infinity | dannf: http://iso.qa.ubuntu.com/qatracker/milestones/374/builds/144350/testcases (please register a result of some sort) | 17:53 |
| javier4 | Hi. I want to apply some modifications to an ubuntu package for armhf. Is this the right way: download orig.tar.gz, apply the related diff.gz, apply my changes, and pass the source dir to sbuild (that I have already configured)? | 18:28 |
| rbasak | Roughly, yes. The dget and dpkg-source tools do these steps for you though. | 18:32 |
| javier4 | rbasak: dpkg-source download automatically the debianized source tarball, or apply the diff.gz after I manually downloaded it? | 18:35 |
| rbasak | javier4: see the dget manpage | 18:35 |
| slangasek | rharper: bug #1673860 still has no SRU bug template, can you get that today? | 18:37 |
| ubottu | bug 1673860 in systemd (Ubuntu Yakkety) "systemd-resolved unit should run Before=network-online.target" [Undecided,New] https://launchpad.net/bugs/1673860 | 18:37 |
| dannf | infinity: done. LP: #1675522 | 18:40 |
| ubottu | Launchpad bug 1675522 in grub2 (Ubuntu) "arm64: Synchronous Exception at 0x00000000BBC129BC" [Undecided,New] https://launchpad.net/bugs/1675522 | 18:40 |
| infinity | dannf: How... Fun. | 18:40 |
| infinity | dannf: So, I guess we shouldn't release that. :/ | 18:41 |
| infinity | dannf: And priotize hunting down WTF ASAP. | 18:41 |
| dannf | yeah, reverting to yakkety grub to see if that's it | 18:41 |
| infinity | dannf: Curious that it's only on REboot. Could be a qemu bug not clearing some registers or something on machine reset? | 18:44 |
| dannf | infinity: yeah, could be | 18:47 |
| dannf | infinity: reproducible w/ yakkety grub. what's weird is that the host is pristine xenial - would've thought we'd seen this problem before | 18:54 |
| infinity | dannf: Is it reproducible with a xenial ISO? If so, I'm inclined to say zesty isn't the problem here, and your boot/install test is a success. | 18:55 |
| dannf | infinity: checking | 18:59 |
| dannf | also testing w/ the yakkety kernel. maybe some hw isn't getting quiesced like it once was | 18:59 |
| dannf | infinity: yep, boot w/ 4.8, reboot to 4.8 works | 19:01 |
| infinity | dannf: kernel shouldn't be involved, in theory. I mean, unless qemu was incorrectly relying on the kernel doing somehting it doesn't have to. | 19:01 |
| dannf | right, not saying it's a kernel *bug* | 19:02 |
| infinity | dannf: If downgrading the kernel works, it still smells like a qemu bug. Since "ask the machine to reboot" should be all that's required for a clean reboot. | 19:02 |
| infinity | dannf: But that also returns us to "the image isn't releasable in that state", so whee. I guess I'll keep it disabled. | 19:02 |
| infinity | dannf: Please make sure this gets escalated/fixed by whomever should be doing the investigation and fixing ASAP. | 19:03 |
| bdmurray | nacc: Is there any migration documention for bug 1668808? | 19:30 |
| ubottu | bug 1668808 in iscsitarget (Ubuntu Xenial) "iscsitarget-dkms 1.4.20.3+svn502-2ubuntu4: iscsitarget kernel module failed to build [error: field ‘rx_hash’ has incomplete type]" [Undecided,In progress] https://launchpad.net/bugs/1668808 | 19:30 |
| nacc | bdmurray: i'm working on it now -- do you think that's appropriate to put in the release notes? or i could also, i guess have put it in the changelog itself! | 19:30 |
| nacc | bdmurray: unfortunately, it's a non-trivial migration (i don't think tgt and ietd are configured similarly) | 19:31 |
| bdmurray | nacc: I think somewhere in the bug is good. Maybe the 16.04 release notes if its not already there. | 19:31 |
| nacc | bdmurray: ack, will provide in both (the latter is not, because the package still exists in 16.04, just doesn't do anything for HWE) | 19:32 |
| nacc | bdmurray: but yeah, i agree, we should document the recommended approach | 19:32 |
| nacc | mabye i'll just point at the server guide which has a tgt/iscsi section i think | 19:32 |
| nacc | bdmurray: and thanks for following up, excellent SRU work :) | 19:33 |
| bdmurray | mwhudson: Does the docker-compose upload in the yakkety queue reference the right bug number? bug 1675288 | 19:47 |
| ubottu | bug 1675288 in runc (Ubuntu) "security fix to runc in docker-1.12.3 wasn't picked" [Undecided,New] https://launchpad.net/bugs/1675288 | 19:47 |
| mitya57 | Can someone please reject metacity from Xenial queue? After uploading I noticed that it FTBFS. | 20:01 |
| infinity | mitya57: Done. | 20:03 |
| mitya57 | thanks | 20:03 |
| infinity | mitya57: (You generally want #ubuntu-release for queue admin requests) | 20:03 |
| mitya57 | OK, will bear that in mind. | 20:04 |
| infinity | dannf: A qemu problem on all releases, or specific to one? | 20:13 |
| dannf | infinity: upgrading the host's qemu from xenial's ver to zesty's seems to fix it | 20:13 |
| infinity | dannf: Hrm. Kay. So should I release that image? | 20:14 |
| dannf | infinity: +1 | 20:14 |
| infinity | Doing. | 20:14 |
| infinity | dannf: That said, anyone running an arm64 cloud is probably doing so on xenial, so please figure out WTF? :) | 20:15 |
| dannf | infinity: yep, we'll figure it out | 20:15 |
| juliank | Things with the two apt srus are a bit strange now. Some bugs got verification-done-xenial verification-needed-yakkety (and a verification-needed), others only got reset from verification-done to verification-needed. | 20:42 |
| juliank | For example: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1657567 has -needed, https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1657440 has -needed, -done-xenial, -needed-yakkety | 20:44 |
| ubottu | Launchpad bug 1657567 in apt (Ubuntu Yakkety) ""Content-Range: */<file size>" on non-416 responses considered invalid" [Low,Fix committed] | 20:44 |
| ubottu | Launchpad bug 1657440 in apt (Ubuntu Yakkety) "apt won't redownload Release.gpg after inconsistent cache updates made while UCA is being updated" [Medium,Fix committed] | 20:44 |
| nacc | bdmurray: re: LP: #1574900 and LP: #1574911, it seems like we're in a bad place beause we're shipping an unmaintained/broken pam-mysql RC that never released (it was subsequently forked and the version in 17.04 is the new repository and working). I spent some time yesterday and could not find a specific change that woudl fix the stack smashing. I could ask upstream to help, but honestly, from an | 20:45 |
| ubottu | Launchpad bug 1574900 in pam-mysql (Ubuntu Yakkety) "libpam-mysql undefined symbol: make_scrambled_password" [Undecided,Fix committed] https://launchpad.net/bugs/1574900 | 20:45 |
| ubottu | Launchpad bug 1574911 in vsftpd (Ubuntu) "vsftpd 500 oops stack smashing detected - Ubuntu 16.04" [Undecided,Confirmed] https://launchpad.net/bugs/1574911 | 20:45 |
| nacc | SRU/LTS perspective, I think we would be better off shipping the actual release (same upstream as in 17.04). An MRE but not a permanent MRE -- thoughts? | 20:45 |
| juliank | How best to clean this up and tag the bugs once verified on yakkety as well? | 20:45 |
| nacc | juliank: i don't think there is any reason not use per-release v-n and v-d tags if they should be there | 20:45 |
| nacc | juliank: but i suppose you should wait for an SRU repsonse :) | 20:46 |
| infinity | juliank: If you're looking to triage it all and make it look sane, drop all the non-release ones and replace with release-specific tags that represent reality. | 20:47 |
| infinity | Our tools kinda suck at doing this consistently, and our users suck even worse at it. | 20:47 |
| juliank | OK, great. | 20:48 |
| juliank | I'll have a look at it in the next days | 20:48 |
| mwhudson | bdmurray: argh what | 21:13 |
| mwhudson | bdmurray: no :) | 21:14 |
| mwhudson | bdmurray: reject pls | 21:16 |
| mwhudson | bdmurray: also xenial | 21:16 |
| mwhudson | bdmurray: i owe you beer sometime in june somewhere in the pacific north west | 21:20 |
| tsimonq2 | mwhudson: Are you going to LFNW? | 21:21 |
| mwhudson | tsimonq2: nah, work sprint | 21:21 |
| tsimonq2 | mwhudson: Aww :P | 21:22 |
| mwhudson | tsimonq2: have two kids under 5, don't get to travel for fun :) | 21:22 |
| tsimonq2 | mwhudson: ;) | 21:23 |
| === nacc_ is now known as nacc | ||
| === infinity changed the topic of #ubuntu-devel to: Zesty Final Beta Released | Archive: post-beta denouement | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!