[00:35] Bah. Why can't you annotate your versioned symbols purely alongside their code? Why must you have a symbols.map file that is invariably wrong in some way? [00:45] tmpRAOF: you can? but there are no good examples of this because the only library that makes use of the pragma approach is glibc, and it's buried under three layers of preprocessing :) [00:46] slangasek: You can? How? [00:46] As far as I can tell you can get _quite_ close with the relevant __asm__, if you try and add a symbol to a version node that doesn't appear in symbols.map the linker barfs. [00:46] Assume there was a “but” in the relevant place there :) [00:47] oh? hmm maybe I'm mistaken then [00:48] I could try again. [00:48] Also, I don't think there's any sane preprocessor I could do to make C++ versioning less painful, but just the C would be nice. [00:58] tmpRAOF: hey [00:59] tmpRAOF: may I ask why you are temporary? [00:59] cyphermox: Because I lost my freenode password, and signed up before having a backup email address was mandatory. [00:59] I'm temporary until the registration on RAOF expires (in another 10 months or so) [00:59] ouch [01:00] * tmpRAOF ponders writing patches for __attribute__(version) [01:08] tmpRAOF: 18 weeks, so 4 months :P [01:10] and it looks like enforcement isn't enabled on RAOF, so you could nick to it anyway and use /msg nickserv identify tmpRAOF passwordhere === tmpRAOF is now known as RAOF [01:10] actually, it's normally 15 weeks, though could be up to 18 at staffer discretion [01:11] I've gotten used to tmpRAOF, having a regular RAOF around is going to be confusing :) [01:12] rww: Ah, I thought that might have been problematic on channels like #dri-devel which require you to be registered in order to post, but apparently just being registered at all qualifies. [01:12] indeed [01:18] You'll just make a few of us think you aren't. ;) [02:42] cyphermox: cjwatson this is a long shot question, but is there a way to get out of the need for grub-install and do something similar to dd'ing u-boot? [03:25] slangasek: re the TB discussion on the DMB candidate pool, we're also not processing a lot of applications, so we aren't growing the base either. [04:26] sergiusens: Context, re: grub-install? [04:26] sergiusens: grub-install *is* doing "something like dding u-boot", except for the (good) part where it's also keeping it up to date. [04:37] infinity: my use case is not having to do a bind mount dance and setting up an armhf image without hassle but I can defer for after st patrick's [04:42] oh wait, I don't use grub on armhf [04:43] but still, I want to avoid doing grub-install from a chroot with a bind mounted root [05:33] how can I apply to become a member of ubuntu-sru? This doesn't seem to be documented anywhere. SRU are a focus of my work since I run LTS, exclusively. [05:34] What I'd like to do is more bug-related work, especially to be able to accept or reject SRU nominations. [05:35] Currently, I can already nominate for a release (as part of being a member in bug-squad, I believe), but somebody else has to accept the nomination. [06:11] Laibsch: If bug triaging is your aim, ubuntu-sru isn't for you. [06:11] Laibsch: We do extensive code review and accept/reject uploads. [06:12] OK. What do you suggest, infinity, to do the accepts/rejects for nominations? I feel that is a neglected area. [06:15] Laibsch: The permissions on that are a bit messy. To be fair, I tend to just accept/reject the nominations when processing uploads, they don't need to be accepted before an upload happens. [06:16] Laibsch: There is a group for nominating, but it has a few too many other permissions, due to that bit not being as fine-grained as it should be, so I'm wary of adding too many people to it. [06:16] That is my impression, too. My aim is to improve visibility. I'd like to visit https://bugs.launchpad.net/ubuntu/trusty/ and see the open tickets still affecting the LTS. [06:17] That is currently not really possible [06:17] Laibsch: Yeah, it's not perfect, I agree. [06:17] I see, understand and respect you are wary to add too many people. Well, here I am requesting to be let in ;-) [06:18] do you know my LP nick? [06:18] wgrant: How much work would it be to fix bug nominations to not require the hackish ~ubuntu-release-nominators team (as a member of drivers, which I assume still has too many permissions to make this hack comfortable)? [06:19] Laibsch: I'm assuming you're ~r0lf [06:19] yup [06:19] good memory ;-) [06:19] infinity: "fix" how? [06:20] wgrant: Well, I'm not sure. To make series nomination something that doesn't rely on drivers? [06:20] Sure, but nobody has been able to define what it should rely on. [06:20] wgrant: I'm fuzzy on how that's all laid out right now. [06:20] Currently bug supervisors can nominate, and drivers or uploaders can approve [06:21] Oh, uploaders can approve? [06:21] Yes. [06:21] Laibsch: There's your solution. Either only triage universe SRUs, or become a core-dev some day. :) [06:21] I'm actually neither ;-) [06:22] Only recently was I granted PPU uploads [06:22] long, ugly story [06:22] I think this https://launchpad.net/ubuntu/+source/gdal/1.11.2+dfsg-1~exp2 is causing vtk6 adt failure and also blocking the whole Qt 5.4.1 landing. [06:22] Mirv: Yeah, I'm working on it. [06:22] infinity: oh, thanks! [06:23] wgrant: Okay, well, that's less broken than I originally thought, at least. [06:24] Laibsch: So, honestly, I'm going to have to just politely decline. But given that any core-dev can approve a nomination, if you see pending ones that you think should be approved, it's not too onerous to ask in here. [06:25] OK. I'll just bug you guys until you get tired of doing it this way ;-) I'd think that rejecting a nomination is equally important to make sure there is a well-defined flow to it and https://bugs.launchpad.net/ubuntu/trusty/+nominations as well as https://bugs.launchpad.net/ubuntu/trusty/ show the true state of affairs. [06:26] for example, I'd suggest to autoreject all 500+ nominations for lucid https://bugs.launchpad.net/ubuntu/lucid/+nominations [06:27] wgrant: I've not been convinced since day one that the nominate->accpet/reject flow made more sense than just "here's a task, let someone wontfix/invalid it if it's crap", but I guess for what it's meant to do, the perms seem alrightish. [06:27] Personally, I think the same is OK for precise https://bugs.launchpad.net/ubuntu/precise/+nominations [06:27] Laibsch: precise is still supported for 2 more years. [06:27] infinity: Well, nominations don't have much value nowadays. [06:27] infinity: Until a few years ago anyone could nominate, so the separate phase made sense. [06:28] wgrant: So maybe just letting bug supervisors have the full privs would make everyone happy? [06:28] infinity: Well, maybe an auto-reject for precise unlike lucid is still not warranted. Combing through the tickets would probably yield 90+% reject rate [06:29] infinity: I don't think that there would be serious issues with letting bug supervisors add series tasks without going through nominations, now that task deletion exists. [06:29] And then nominations can conveniently cease to exist. [06:29] Wow, there are still open bug nominations for hardy! 170 of them [06:30] Laibsch: See, I fundamentally disagree with you (but I think that means I disagree with the nomination model). If a bug exists in precise, it should have a precise task. If the people responsible for fixing it decide they don't want to, they can mention that and WontFix it, but "I don't want to" doesn't make a bug not a bug. [06:30] wgrant: Yeah, I think I'd like that better. [06:30] https://bugs.launchpad.net/ubuntu/+source/kbd-chooser/+bug/27284 that one's nominated all the way back through to dapper! [06:30] Launchpad bug 27284 in kbd-chooser (Ubuntu) "Wrong configuration of keyboard" [High,Confirmed] [06:31] wgrant: And then I could delete that hackish group wholesale, which would make me happy. [06:31] wgrant: It's never sat well with me. [06:32] infinity: Doesn't it also exist for blueprint targeting? [06:32] infinity: I agree with the a bug that is present is a bug. Oftentimes, I do argue that case. But I guess most bugs like that if they have been sitting around are ignored. Certainly any nomination before hardy should be auto-rejected as a part of clean-up. [06:32] Which is why UDS organisers etc. used to be in there. [06:32] wgrant: In theory, not sure anyone uses it for that anymore. [06:33] Laibsch: Sure, nominations on EOL releases should be cleaned up, no argument there. [06:33] * Laibsch has done some of those in the past [06:33] I was only able to do that if the nomination had been accepted [06:33] Laibsch: But "old open bugs" on non-EOL releases are not a problem. Driving bug counts to 0 by FIXING bugs is a noble goal. Artificially driving bug counts to 0 by closing valid bugs is not. [06:34] if a bug is nominated but not accepted yet, I'm stuck [06:34] like bug 27284 which could be cleaned up on the dapper to jaunty part [06:34] bug 27284 in kbd-chooser (Ubuntu) "Wrong configuration of keyboard" [High,Confirmed] https://launchpad.net/bugs/27284 [06:34] wgrant: Anyhow, at the very least, we could prune the team, which would make me happy. [06:35] infinity: no disagreement. I believe in fixing bugs, not reducing ticket count. The latter comes from the former. [06:35] But I also like a good dashboard which LP mostly is. But as I mentioned I am currently stuck on certain things. [06:36] Laibsch: Yeah, I agree (obviously) that the nomination thing isn't ideal. [06:36] Well, I kind of like it. But I see the problem you with it from a managerial POV. [06:37] "have with it" [06:37] Laibsch: Well, if only bugcontrol can nominate, and bugcontrol are the people I'd prefer to be approving or rejecting nominations, then may as well just do away with the process. :P [06:38] Sure. I'd be happy with that too, being a member of bugcontrol. [06:38] is that where you will be heading, then? [06:39] I think that was the rough concensus between wgrant and I, though we might want to think about it a bit more before changing how something's been for years. [06:39] Right, the nomination process doesn't provide much value now that nominations themselves are restricted. [06:39] Laibsch: But, for now, asking works. Sucks, but works. [06:39] hmm, looks like that gdal transition might be a bit bigger one. things like rebuilding qgis would take hours. [06:39] Mirv: Yeah, I didn't say it would be instant. [06:39] We should check with others, and think about it, but it's a lot of complexity for not much gain. [06:40] no problem [06:41] wgrant: Well, we could fudge it for now by giving bugcontrol nomination approval perms, which effectively removes the step without removing the code. [06:41] wgrant: And then further discuss if the code itself is even useful. [06:41] infinity: The code is broken anyway, so I want to delete it :P [06:41] Heh. [06:42] infinity: just to be sure I understand the outcome of this discussion. Are you (or somebody else) going to allow bugcontrol to ACK/reject nominations some time soonish? I'm not sure I understand what the consensus is where the train will be heading. [06:42] Good old bug #110195 [06:42] bug 110195 in Launchpad itself "Nominating a bug for a distro series affects all package tasks for that distro" [Critical,Triaged] https://launchpad.net/bugs/110195 [06:42] I reported it nearly eight years ago... [06:42] wgrant: Maybe when Colin wakes up? I don't think this needs management buy-in (in fact, I imagine that would just invite bikeshedding), between the three of us, we should be able to decide the fate of the feature reasonably. [06:43] wgrant: Is the two-step nominate/approve process used for non-distro products too? [06:43] wgrant: Or is it a case of "well, the code would allow that, but no permission split exists to expose the UI to other projects". [06:43] infinity: It is. [06:43] Products have the driver/bugsupervisor split just like Ubuntu. [06:43] Kay. [06:44] So, I think that's the discussion to have. [06:44] Cause for Ubuntu, I can confidently say this has sucked for ages, and giving bugcontrol actual control over bugs would be fine by me. [06:44] If they abuse it, they can be removed from the team, splitting perms doesn't make idiots stop being idiots. [06:45] Exactly. [06:46] For something that can at worst cause annoyance, we just need a barrier to stop any user at all from doing it. [06:46] As soon as you have that barrier, you can easily slap anyone who abuses it. [07:07] kindly requesting to set the vivid task of bug 1273203 to fix released. Bonus points for actually processing the trusty task ;-) [07:07] bug 1273203 in ubuntu-restricted-extras (Ubuntu Trusty) "ubuntu-restricted-extras Recommends unavailable package: libavcodec-extra-53" [Medium,Triaged] https://launchpad.net/bugs/1273203 [07:08] Laibsch: That's a case of "you shouldn't have nominated it". [07:09] Laibsch: A nomination to the development release is redundant. [07:09] why is it available, then? ;-) [07:09] I nominated in case it wasn't going to get fixed before the release cycle [07:09] but I agree it creates unnecessary work now [07:09] I'd clean up after myself if I was able to === kickinz1|afk is now known as kickinz1 [07:10] Laibsch: As for the debdiff there for trusty, 60ubuntu0.1 is the correct version. [07:11] well, I'm aware of that. I find my version more informative. See my comment. I checked all releases to make sure this one would work. [07:11] Laibsch: Oh, wait. No. It's ubuntu-native. The correct version would just be 60.1 [07:12] IMVHO 60ubuntu0.1 suggests this was a version not part of ubuntu which isn't the case. [07:12] it's a branch-off, not a backport [07:12] Laibsch: Right, it should just be 60.1 [07:12] I'll sponsor it as such. [07:13] OK, I won't fight over that. I still prefer seeing the release name in these sometimes quite long package version numbers. [07:13] when possible [07:13] infinity: thanks, btw [07:13] Laibsch: Which is entirely against our versioning policy. :P [07:14] Laibsch: (And release names are always wrong in versions, if you really need to ref a release, say for a backport, it should be the number, so they sort correctly) [07:14] I understood the version policy to be "we suggest this, but we only require you not to break anything" [07:14] well, and again, I don't like only numbers [07:15] Laibsch: And after the Z release, when the next one sorts earlier? :) [07:15] 1.4.11-1 is hard to spot from 1.4.11.1-1 etc [07:15] still some time for the Z release [07:15] Laibsch: It's not about what you like, people have actually thought about this. [07:15] I'm sure that will create all sorts of problems of its own and I am sure someone will figure those out [07:16] well, trust me, I have thought about this, too. And I find it important to be able to actually "read" the version number, especially when they get long. And I know my version won't break anything and will do what I am trying to do which is readability in this case. [07:17] SRU numbers tend to get longer and longer [07:17] so, again, IMVHO I think the release is better than just numbers [07:17] release name [07:18] Laibsch: SRU versions don't get longer and longer... The next one after 60.1 is 60.2 [07:19] What i meant is they get longer than what was initially released [07:19] which can be quite long on its own already [07:19] Laibsch: Anyhow, let me put it differently. You can have whatever opinion you like, I'd reject the upload if it had that version. [07:19] fair enough ;-) [07:20] Laibsch: And side note, you also missed the "#" in your bug closure syntax. [07:20] * Laibsch hangs head low in shame [07:21] BTW, the wording on https://wiki.ubuntu.com/StableReleaseUpdates is as I remembered and permissive: "The version number does not conflict with any later and future version in other Ubuntu releases (the security policy document has a well-working scheme which can be used for SRUs.) " [07:21] * Laibsch hopes the text won't get changed now [07:21] "can be used for SRUs" not "has to be followed" [07:24] infinity: And I agree with your suggestion of 60.1 being better than 60ubuntu0.1 but that is not what https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging suggests [07:24] Laibsch: Yes, I know it's quite permissive (maybe we should make it less so), but we also reserve the right to reject something for whatever silly reason we like, so most "bad" version numbers don't make it through. [07:24] like I said, I HAVE thought about this [07:25] Laibsch: The security doc misses the case where a native version is ubuntu-native, not debian-native. [07:25] infinity: hehe, your version number is bad as per wiki (although IMVHO it is better than the one suggested there) [07:25] Laibsch: If this was a debian-native package, 60ubuntu0.1 would have been correct. [07:29] Laibsch: Anyhow, sponsored for both vivid and utopic, and since it was trivial enough that I really didn't feel it needed to be reviewed twice, accepted too. [07:29] awesome, thanks [07:29] I thought it was already in vivid? [07:29] * Laibsch checks [07:29] Laibsch: Err, trusty and utopic. [07:29] Laibsch: I don't brain so good. [07:30] Ah, utopic [08:10] “ Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!” — cjwatson, perhaps time to find some new ops? :-) [08:10] infinity: did you note libgdal-grass failed? it seems to expect same version number as gdal itself in the build scripts [08:12] good morning [09:14] Mirv: I did, yes. I'll sort it out after the rebuilding stuff. [09:15] Mirv: Either way, looks like Qt migrated now, with the vtk autopkgtest fixed. [09:19] Can someone explain why we are running a version of rsyslog which is so old ? (7.4.4 .vs. jessie's 8.4.2) ? [09:19] infinity: ok. and yes, excellent! [09:20] caribou: Because no one's merged it since trusty. [09:21] infinity: any reason for that other than no one wanted to ? [09:21] caribou: That said, rsyslog releases don't tend to be action-packed, is there an issue with the current version? [09:21] caribou: I assume it just slipped off the radar, it happens. [09:21] I have people complaining about memory leak on Trusty [09:21] I've tracked a few but apparently more remains [09:23] caribou: Okay, well, then I guess you get to backport some fixes to trusty. It's not like an LTS keeps shiny new versions for 5 years. [09:23] infinity: yeah, that's what I'm looking at; was just curious to know why it hadn't moved. 7.4.4 is no longer maintained upstream as fas as I know [09:24] no, that last statement is false [09:26] mlankhorst, Is there anything you need me to test on xorg today? [09:27] mlankhorst, My time is a little limited however. [09:27] caribou: Many things we ship aren't supported upstream, that's how stable releases work. [09:27] caribou: We take on that burden. Sucks to be us. [09:27] mlankhorst, Also Xorg on PowerPC is completely broken right now too. [09:28] infinity: I did fix something in precise, that's when upstream told me it was no longer supported, but asked me for a patch for the 7 release [09:28] mlankhorst, Saw it reported by the PowerPC guys and upgrade my iBook G4 running Ubuntu MATE 15.04. Lots of screen flashing/flipping and no way to interrupt it. [09:44] tjaalton: hey [09:44] tjaalton: I'd like to talk about bug 1381625 [09:44] bug 1381625 in linux (Ubuntu) "Adjust brightness to lowest value caused screen whole black" [High,Confirmed] https://launchpad.net/bugs/1381625 === vrruiz_ is now known as rvr [09:52] * tjaalton runs [09:52] zyga: what about it [09:52] tjaalton: hey [09:52] tjaalton: I'm doing a small research project about this issue [09:52] tjaalton: I've updated the bug report with that [09:53] tjaalton: I wanted to ask you about your opinion on this [09:53] tjaalton: and to know if that kind of data could be of use [09:53] tjaalton: and if not, what else could help [09:53] * sladen just *wishes* it was possible to turn the backlight down that far on other laptops [09:54] well, I can ask the intel devs.. [09:54] I can't fix that myself [09:54] the VBT spec isn't open either [09:55] tjaalton: can we patch it in userspace though? patch apps to go to 0 on firmware and on max_brigthness * 0.1 on raw? [09:56] sladen: down to off? [09:57] tjaalton: if you ask intel please share anything they tell us [09:57] tjaalton: does it require an NDA? [09:58] no [09:58] tjaalton: I don't know if we can do it quickly but for preinstalled laptops we could even ship a backligth profile with behavior data === Laibsch1 is now known as Laibsch [10:02] I'll check my hw what they're like [10:05] tjaalton: can you use lantern please? [10:05] tjaalton: the more data we have the better we understand how this behaves [10:05] tjaalton: specifically follow that please http://www.zygoon.pl/2015/03/lantern-update.html [10:05] tjaalton: you can send the results by email or just send a pull request with the new json file [10:05] ok [10:08] tjaalton: thanks! [10:08] tjaalton: if you want to do the analysis part: http://www.zygoon.pl/2015/03/analyzing-lantern-submissions.html [10:13] flexiondotorg: I'll create a ppa3 in a bit === doko_ is now known as doko [10:57] sergiusens: You can decompose grub-install into its pieces (grub-mkimage and grub-bios-setup, basically, on PC BIOS systems; grub-mkimage and what amounts to cp on UEFI) and run them manually if you really want and are comfortable with owning both pieces if it breaks. The reason it normally requires a chroot is that that's by far the easiest way to deal with automatically computing which module names must be passed to grub-mkimage for ... [10:58] ... being built into the core image. And there's a bunch of files such as modules that you need to copy into place under /boot/grub/ if you aren't using grub-install. [10:58] sergiusens: I can't say I recommend this; it's usually more effort than dealing with bind-mounting stuff to run grub-install. [10:59] sergiusens: (There are some workflows where it's reasonable to build a single giant monolithic core image and not expect it to do module loading at run-time, in which case it's simpler.) [10:59] cjwatson: ok, I'll take the recommendation into account, my other goal which I did't mention was to not need root to create these images (but that's a further away problem) [11:00] smoser: fyi ^ [11:02] sergiusens: Well, for an image that isn't actually installed to a computer's boot sector, grub-install is conceptually inappropriate anyway. [11:02] grub-install is a thing you do on a computer that will be booted using GRUB. [11:02] It's more like a deployment step. [11:03] You can do the grub-mkimage parts in advance if for some reason it's unreasonable to do those on the deployed system. [11:05] I need to give this some thought, these are mostly VMs, cloud images or dd'able image files [11:08] mlankhorst, Ping me when ppa3 is ready and I will test. I'll also re-test my PowerPC using it later tonight too. [11:16] didrocks, hi, what is your python-pip change about? reading the changelog, it allows a sudo pip install to overwrite distro packaged stuff, which we want to avoid [11:20] doko: it's just fallbacking to the upstream /usr/local behavior if it's run as root [11:21] doko: that way, we don't break potential existing scripts [11:21] didrocks, and you make sure that it doesn't work with /usr and root ? [11:21] doko: I just fallback to upstream behavior (not sure if you follow the upstream discussion that happened with my previous patch to set user mode by default) [11:22] no, that's why I was confused ... [11:22] doko: look at my previous patch first I guess, basically for root, this is a non change compared to utopic [11:23] ok [11:24] jamespage, the python-defaults upload triggered a lot of autopkg tests, neutron and swift now failing. I suppose that's something else than the dependency package triggering these [11:25] doko, working on neutron atm - will look at swift next [11:25] doko, neutron broke during the systemd switch - but its not directly attributable [11:29] jibel: can we ignore the taskcoach autopkg test failure? seems unrelated to the python-defaults change, and failing since Oct [11:30] doko, didrocks was just chatting w/dstufft. watch the tracker issue for some progress on --user [11:31] jibel, wait, I'll merge the Debian version first [11:33] barry: ah nice, there was still nothing yesterday AFAIK, hence this fix to at least not break scripts! [11:33] barry: keep us posted :) [11:42] * Laibsch pings infinity now that cjwatson seems to be awake [11:42] good morning, cjwatson! [11:44] I saw the discussion; I don't know if I have strong feelings. Task deletion indeed makes many things better, although it's not perfect (IIRC you can't re-add a task that's once been deleted), but that probably doesn't matter for this case. But we would have to look at how other projects are using it in LP, if at all. [11:51] cjwatson: The task delete/recreate bug should probably not define if we need a feature to work around it. :) === _salem is now known as salem_ [11:52] Though, in my world, I work around it by wontfixing/invaliding instead of deleting. I've learned my lesson. === paulliu1 is now known as paulliu [12:06] infinity, cjwatson: So, what is the next step now? === txspud|ORS is now known as txspud [12:18] Laibsch: We go talk about it a bit and maybe things change at some point. If you were expecting a resolution today, you might be disappointed. [12:18] Laibsch: It's been like this for years, this is hardly a critically urgent bug or feature change. [12:18] it's an honest question, no expectation beyond "OK, we talked about it and then it's going to drop off the radar" [12:19] beyond the quote not happening [12:20] Laibsch: I think we've covered most of the "talking about it" step. :) [12:20] it sounded reassuring that you were confident to get a decision between the three of you. the more people involved the more difficult to progress. so, my honest question is where this stands. [12:20] Laibsch: William clearly has a preference for dropping the feature altogether, I'd like to see bugcontrol's permissions elevated, Colin wants to make sure others aren't in dire nead of the feature before agreeing with William, and there we are for now. [12:21] infinity: perhaps you should put it onto the foundations->lp stakeholder backlog? [12:21] infinity: sounds like your choice won't conflict with the other two [12:21] so maybe that is a good interim solution [12:21] it would make me happy, too ;-) [12:22] cjwatson: Perhaps I should. Or we could just do the permissions elevation bit as a bite-sized deal, and revisit the "drop the whole feature" thing another time. [12:22] * Laibsch applauds infinity's proposal from the side-line === Malsasa_ is now known as Malsasa [12:25] cjwatson: The task deletion reversal bug is half the reason I want to delete nominations. === kickinz1 is now known as kickinz1|afk === kickinz1|afk is now known as kickinz1 [12:26] The underlying problem is that nominations are for a DistroSeries, not a SourcePackage. So if you remove a subset of them, the nomination is half-removed. [12:26] If nominations go away, one could presumably add a single SourcePackage task directly. [13:13] does somebody know if having a \ in systemd unit name (run-vmblock\x2dfuse.mount) is supported by all the systemd packaging helpers? === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [14:05] kindly accept the trusty nomination for bug 1395061 [14:05] bug 1395061 in pinta (Ubuntu) "Pinta throws unhandled exception when invoking CUT (^X) or COPY (^C)" [Medium,Fix released] https://launchpad.net/bugs/1395061 [14:07] Laibsch: done [14:10] jibel, taskcoach is failing. can you overwrite this permanently? [14:16] doko, I am not allowed to do that, infinity can you help^ [14:17] jibel, well, debian disabled the test, but it would need an overwrite too then, if we disable it? [14:24] would anyone here ( infinity, pitti ? ) object to moving /lib/init/apparmor-profile-load from upstart-bin into init-system-helpers? [14:24] jodh: ^ bringing it up here [14:25] * hallyn_ biab [14:27] ^^ maybe one for jjohansen or jdstrand? [14:27] Does it even really belong in init-related stuff? Or should it be in apparmor packaging? [14:28] (now that both upstart and systemd have built-in apparmor profile loading support)? [14:39] hallyn_: I agree with rbasak that it makes sense to provide it as part of the apparmor package [14:44] tyhicks: but upstart jobs may use it [14:44] *it* properly checks for whether scripts it uses are available, so that things calling it don't have to [14:45] of course on ubuntu we'd rarely see a case where apparmor wasn't installed, so it would hide the problem, but i don't think it would be the best solution [14:47] hallyn_: in >= Vivid, we wouldn't ever have a case when an upstart job runs any more though right? [14:48] hallyn_: and apparmor jobs should move to using "apparmor load" instead now. So it's just support during a transition period that we need, and moving it to the apparmor package won't break that since no upstart jobs will run in Vivid. [14:48] Oh, I suppose phone. [14:49] Maybe we just need to search the archive, find upstart jobs that use it and fix it. [14:51] rbasak: there may be ppl wanting to run upstart [14:52] oh, right, phone too [14:52] rbasak: but what is the reason to not put it into init-system-helpers? [14:53] it's exactly what it is :) [14:53] hallyn_: apparmor isn't just for init. [14:53] (AIUI, anyway) [14:53] So why does it belong there? [14:54] bc every system has an init [14:54] By that logic all files in the system should be moved to init-system-helpers :) [14:54] simplifies my life [14:54] so +1 [14:54] jodh: ^ ok, so if we move it into apparmor, will it break a lot of upstart jobs? [14:55] putting it into apparmor is fine by me, suffices for lxc === hallyn_ is now known as hallyn [15:02] rbasak: apparmor support in systemd is still pretty basic [15:03] tyhicks: meaning what exactly? that shouldn't affect whether that script can go into apparmor right? (and you suggested it, so i assume not :) [15:04] tyhicks, hallyn: I get the case that it's convenient to wrap the test for apparmor into something in init-system-helpers so that init scripts don't have to each explicitly test themselves. [15:04] if noone (jodh, rbasak, tyhicks, infinity, stgraber) objects I can move the script [15:04] The functionlity itself though I think belongs to apparmor. [15:05] I didn't consider this split before, and I'm not sure what's where right now in terms of it. [15:05] rbasak: the functionality is in apparmor :) the script is a pretty basic wrapper [15:05] 30 line script [15:05] hallyn: no, that shouldn't affect where the script lives [15:05] otoh it does do some fugly checking of /sys etc, so... [15:05] tyhicks: so my suggestion would actually be, [15:06] hallyn: yeah. Looking at it I think that intelligence should be in apparmor [15:06] apparmor pkg gains a script with most of the intelligence, called /lib/init/apparmor-profile-load.real or soemething, [15:06] How about moving it to apparmor under a different name? [15:06] and the init-script-helpers has a wrapper script just returning nothing if apparmor is not installed [15:06] hallyn: well we'd need to trawl all the packages, but on my vivid system only the now-unused /etc/init/ jobs are using /lib/init/apparmor-profile-load directly whilst session jobs are using the apparmor stanza (which calls /sbin/apparmor_parser directly). [15:06] Leave the path /lib/init/apparmor-profile-load managed by init-system-helpers [15:06] Make /lib/init/apparmor-profile-load a simple run-if-exists to the new name provided by apparmor [15:06] Then no backward compatibilty issues [15:06] rbasak: right [15:07] hallyn: I don't know what I'm objecting to, but I like objecting. [15:07] it's usuallythe safe route [15:07] rbasak: do you have time to come up with proposed packages? :) [15:08] * hallyn biab [15:08] you both came up with the same proposal and it seems like a good approach :) [15:09] What's the appropriate path for apparmor? [15:10] /usr/share/apparmor/profile-load or something? [15:11] I assume that the script is in /lib because it needs to be available very early in boot [15:11] I don't think /usr/share will do in that case [15:11] Good point [15:11] I see /lib/apparmor is already used [15:11] /lib/apparmor/profile-load? [15:12] that works for me [15:22] Laney: hey, i have a webkit-based browser that i use; switching from utopic to vivid, when i pull up a new browser i always have to log back in (to github, lp, whatever). it does seem to be reading my cookies file fine according to strace [15:22] just wondering, any idea where i woudl track that down? [15:22] (asking you since you see mto have merged it from debian, maybe you owrk iwth it sometimes) [15:23] if not i'll just start bisecting (or whatever i can do with their upstream :) [15:25] hallyn: afraid not - try #webkitgtk+ [15:25] ok, thx [15:26] Hello, i have pushed a new package to repository, that contains less files by the previous package [15:27] lefteris: It usually helps if you tell us what package you're talking about, so we don't have to guess, and then perhaps tell us what problem you think you've caused. [15:27] why the extra files does't removing from the system when I install the new package? [15:28] lefteris: If those files are in /etc, they're conffiles, and dpkg treats them specially. [15:28] in which directory are those extra files? [15:29] infinity: wow, ok [15:29] lefteris: See "man dpkg-maintscript-helper", specifically the "rm_conffile" bits. [15:29] that's the problem [15:30] infinity: thx u for the help === gusnan is now known as Guest39122 [16:04] dholbach, hi, how do you feel about sponsoring virtualbox from debian/experimental? just a bugfix release, but really important because of the conflicts fixes [16:04] should I open a bug? [16:04] no, sorry [16:04] in a call now [16:04] and have to figure out a few things [16:04] better file a bug, yes [16:05] didn't ask to sync :) [16:05] it has been just uploaded :) [16:05] well thanks! [16:05] rock on! :) [16:07] the question was "are we just too late in the release cycle?" [16:07] :) [16:09] syncing it (aka bug 1433678) will be the first step to get bug 1429614 fixed I guess :) [16:09] bug 1433678 in virtualbox-guest-additions-iso (Ubuntu) "please merge virtualbox/virtualbox-guest-additions-iso from debian experimental" [Undecided,New] https://launchpad.net/bugs/1433678 [16:09] bug 1429614 in virtualbox-guest-additions-iso (Ubuntu) "[SRU] virtualbox and virtualbox-guest-additions-iso doesn't conflict anymore with the official packages." [Undecided,New] https://launchpad.net/bugs/1429614 [16:09] and recursively also (LP: #1371287, LP: #1375018, LP: #1385931, LP: #1386328, LP: #1421926) [16:10] Launchpad bug 1371287 in virtualbox (Ubuntu) "package virtualbox 4.3.14-dfsg-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1371287 [16:10] Launchpad bug 1375018 in virtualbox (Ubuntu) "package virtualbox 4.3.14-dfsg-1build1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Confirmed] https://launchpad.net/bugs/1375018 [16:10] Launchpad bug 1385931 in virtualbox (Ubuntu) "package virtualbox (not installed) failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1385931 [16:10] Launchpad bug 1386328 in virtualbox (Ubuntu) "package virtualbox 4.3.18-dfsg-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1386328 [16:10] Launchpad bug 1421926 in virtualbox (Ubuntu) "package virtualbox 4.3.18-dfsg-2ubuntu1 [modified: usr/lib/virtualbox/VBoxDDU.so usr/lib/virtualbox/VBoxHeadless usr/lib/virtualbox/VBoxNetAdpCtl usr/lib/virtualbox/VBoxNetDHCP usr/lib/virtualbox/VBoxOGLhostcrutil.so usr/lib/virtualbox/VBoxRT.so usr/lib/virtualbox/VBoxSDL usr/lib/virtualbox/VBoxXPCOM.so usr/lib/virtualbox/webtest] failed to install/upgrade: subprocess installed post-installation script re [16:10] and many many other bugs [16:11] (sorry for the noise, ubottu seems to pick up also LP: #) [16:14] LocutusOfBorg1: syncing is fine, but LP hasn't yet picked it up so I can't do it now [16:21] tseliot: Any ideas on the ubuntu-drivers-common autopkgtests being completely broken? [16:22] infinity: I added a couple of tests but they ran fine here. I'll look into that soon [16:22] tseliot: All looks very explodey in production. :P [16:22] https://jenkins.qa.ubuntu.com/job/vivid-adt-ubuntu-drivers-common/lastBuild/ [16:24] infinity: from what I can see, even tests that I didn't touch now fail [16:25] I'm wondering if it has anything to do with this error: [16:25] ERROR: ld.so: object 'libumockdev-preload.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. [16:26] tseliot: I see that occasionally in the last successful run too. [16:26] smoser: How are new versions of cloud-init packaged; is it (in the general case) just `cp -r` and a changelog entry? [16:26] hmm... ok [16:27] Though, certainly not as often. [16:27] thanks mitya57 [16:28] Odd_Bloke, packaged as in for ubuntu or as in for "upstream tarball" [16:28] infinity: I'm rebuilding using sbuild (again) to see if I can reproduce the issue [16:29] tseliot: Might be a case of tests that pass when run in the build tree, but not when run against the installed packages? [16:30] smoser: Packaged for Ubuntu. [16:30] see debian/README.source . [16:31] for vivid, i just follow the '== New snapshot ==' [16:31] and then for releases, i do the quilt / single patch stuff [16:31] smoser: Ack, thanks. [16:32] infinity: yes, it's probably that, as the build completed successfully here [16:38]