[00:10] <bdmurray> arges: the state of bug 1401523 is rather odd? comment #8 mentions precsie but the lucid task was change and comment #9 mentions lucid and no task was changed. Do you know what might have happened?
[00:15] <slangasek> mlankhorst: hi, I've been looking over the last of the LTS stack uploads for 14.04.2, and noticed that xorg-server-lts-utopic is at version 1.16.2.901... when utopic itself is only at 1.16.0.  Can you explain the discrepancy?
[00:16] <slangasek> RAOF: ^^ or maybe you have some context for this
[00:17] <RAOF> Hm. Did I fail to question mlankhorst about that?
[00:18] <RAOF> Huh. Seems I didn't include that with my other queries.
[00:19] <slangasek> RAOF: ah, do you have outstanding queries?
[00:19] <slangasek> RAOF: I just reviewed the mesa one and it looked to me like it checked out, hope I haven't screwed anything up
[00:19] <RAOF> A couple of nitpicks.
[00:20] <slangasek> nitpicks can presumably be fixed post-accept then
[00:20] <RAOF> Stuff like the empty Conflicts: stanzas and such.
[00:20] <RAOF> Yeah, can be fixed post-accept.
[00:22] <RAOF> I think I may be missing something, though. Maarten was resistant to fixing some clearly-incorrect things that I queried. They might be difficult to entirely script, but seemed like they could be trivial to fix (and quicker to fix than to argue about ☺) before uploading.
[00:23] <slangasek> right, AIUI the lts-* package translations are completely automatic at this point
[00:24] <slangasek> so if he fixed them by hand this time, would it just regress with the next upload etc
[00:24] <RAOF> Well, it'd be something that would need to be done for each upload, yes.
[00:25] <infinity> Or fix the tools.
[00:25] <infinity> Because that's the only road to consistency.
[00:25] <infinity> "It's hard" isn't a good enough excuse to not fix something.
[00:25] <RAOF> The ability to easily fix sed is limited :)
[00:26] <infinity> RAOF: Fix sed? :P
[00:26] <RAOF> :)
[00:26] <infinity> RAOF: Oh, like empty Conflicts?  That'll wash out in dpkg-gencontrol (it won't show up in the binary).
[00:26] <infinity> Fairly sure, anyway.
[00:27] <infinity> That said, line deletion in sed isn't rocket science.
[00:27] <RAOF> And I guess won't show up in further debdiffs.
[00:27] <RAOF> But an incorrect Homepage: field will.
[00:28] <infinity> An incorrect Homepage would be incorrect in both the source and the destination of the backport, no?
[00:28] <infinity> So, it should be fixed in both or neither.
[00:28] <infinity> Not worth a nitpick for just the backport.
[00:28] <RAOF> No, the backport script *changes* the Homepage field so as to be incorrect.
[00:28] <infinity> RAOF: ...
[00:28] <infinity> Why would it even touch it?
[00:29] <RAOF> Because it doesn't understand debian/control at all, it just runs sed s/xf86-video-mtrack/xf86-video-mtrack-lts-utopic/g over it?
[00:29] <infinity> RAOF: Oh, is it some overexhuberant "s/$package/lts-$package/" across all of debian/control?
[00:29] <infinity> Yeah.
[00:29] <infinity> That's silly.
[00:30] <RAOF> Right.
[00:31] <infinity> For 1-line fields, that's easy to limit scope, but I can see if he wants to hit up descriptions or line-wrapped deps, it gets tougher without actually processing rfc822 properly.
[00:31] <infinity> Which would stop being a job for sed and start being a job for awk, at the leanest, or a perl or python module, at the heaviest.
[00:32] <slangasek> '/Homepage/ ! { [...] }'
[00:32] <slangasek> fixed
[00:32] <infinity> slangasek: Oh, sure, EXCLUDING fields is easy, I meant limiting inclusion to only certain ones can be tough.
[00:32] <slangasek> true
[00:33] <slangasek> but if the only bug so far is with Homepage, JFDI and move on
[00:33] <infinity> Yeah.
[00:34] <infinity> slangasek: Though, the Homepage thing is a cosmetic bug, the worrying bug is the unbounded replacement, which could theoretically have other consequences $later.
[00:34] <slangasek> RAOF: and xf86-input-wacom-lts-utopic looks fine to me, have I missed something?
[00:34] <infinity> Not that I'd reject an upload because of a tooling bug that might break on a subsequent upload. :P
[00:35] <RAOF> slangasek: No, I must have just missed that in my batch clicking.
[00:35] <slangasek> infinity: right, well, you could also fix it by fixing the sed to word boundaries, since the package name isn't going to appear on its own in other fields
[00:35] <slangasek> RAOF: ok, accepted
[00:35] <slangasek> RAOF: did xserver-xorg-video-intel-lts-utopic also get reviewed?
[00:36] <RAOF> slangasek: No.
[00:36] <infinity> slangasek: Right, and that fixes the most obvious potential bug, which is "what if your package name is a substring of another package name that happens to also show up in debian/control?"
[00:37] <slangasek> q fetch xserver-xorg-video-intel-lts-utopic-antidisestablishmentarianism
[00:37] <RAOF> Oh, you have some extra tools not in ubuntu-archive-tools?
[00:38] <infinity> mlankhorst: Fixing RAOF's Homepage complaint, and the above potential bug could be done by implementing slangasek's suggestion to make your packagename substitutions bound on word separators.
[00:38]  * RAOF was meaning to ask about that; it was somewhat cumbersome to review those things
[00:38] <infinity> RAOF: q is queue.
[00:38] <slangasek> yeah
[00:38] <infinity> RAOF: For hysterical raisins, many people have it aliased.
[00:38] <slangasek> cjwatson brand raisins
[00:39] <slangasek> (I'm sure he'll appreciate that highlight)
[00:39] <RAOF> Ah, I'm missing pytz so didn't get the help for that.
[00:40] <slangasek> mlankhorst, RAOF: similar issue with xserver-xorg-video-intel; the version in the SRU queue doesn't match the version in utopic (2.99.916 vs. 2.99.914)
[00:41] <infinity> Also, I haven't checked the fallout yet, but were these all being overridden to the right component (main/universe, as appropriate, based on their location in utopic) before accepting?
[00:41] <RAOF> infinity: I'm pretty sure I got the overrides right
[00:41] <infinity> RAOF: Kay.  I'll be double-checking anyway, but saves a bunch of pain if it turns out to be right. :)
[00:42] <infinity> mesa-lts-utopic is wrong.
[00:42] <infinity> Was that vorlon's fault just now?
[00:42] <RAOF> Yes :P
[00:43] <infinity> I wonder if he highlights on vorlon on networks where here's slangasek.
[00:46] <slangasek> infinity: what did I miss?  oh, the component?
[00:46] <slangasek> yeah sorry
[00:50] <infinity> slangasek: I'll fix.
[00:50] <infinity> slangasek: Did you miss any others too?
[00:51] <Snow-Man> infinity: alright, I'm up on the new -45 w/ all my boxen.
[00:51] <Snow-Man> Nothing's crashed yet.
[00:51] <slangasek> infinity: xf86-input-wacom-lts-utopic
[00:51] <slangasek> infinity: I'm consistent
[00:54] <infinity> slangasek: I'll just override the rest in the queue now.
[00:54] <slangasek> ack
[00:54] <infinity> And done.
[00:58] <cjwatson> slangasek: I thiiiiink 'q' was a Keybuk thing, but not sure
[00:58] <elmo> infinity: he does
[00:58] <infinity> elmo: And so do you?
[00:58] <cjwatson> would've been back when new-cycle auto-syncs were a multi-day nightmare
[00:59] <cjwatson> infinity: elmo just highlights on everything, to save time
[01:00] <infinity> Smart.
[01:03] <infinity> cjwatson: Hey, launchpad guy.  If a source is accepted in universe, goes dep-wait, and is overriden to main before the dep-wait clears, will the build happen in main or universe?
[01:05] <infinity> cjwatson: I'm pretty sure it does the lookup at dispatch time, and that's what buildd-manager feeds to the slave, but I can never remember if that's fact or wishful thinking.
[01:05] <infinity> wgrant: Since it's more your working hours. ^
[01:07] <cjwatson> dispatch time, yes
[01:08] <wgrant> As Colin says.
[01:08] <infinity> cjwatson: Also, I'd be inclined to blame pitti, since I think his entire life revolves around single-char aliases.  But that might not work, cause 'q' might predate him being an AA.
[01:09] <infinity> The best gift we could give him would be a keyboard with twice as many keys.
[01:09] <cjwatson> could be
[01:09] <slangasek> y
[01:09] <cjwatson> I think m for madison-lite was my fault though
[02:48] <arges> bdmurray: i reviewed it for precise/lucid; When I did the precise 'sru-review' I ctrl-c'd the window accidentally and forgot to flip the bugstate after adding the message.
[05:29] <bdmurray> arges: okay, just wanted to make sure some tool wasn't broken
[06:13] <Unit193> pitti: Howdy.
[06:13] <pitti> LocutusOfBorg1: samba merge> if you want to, please :) Happy to sponsor
[06:15] <pitti> hey Unit193
[06:15] <pitti> Good morning
[06:15] <pitti> infinity: h!
[06:18] <pitti> xnox: \o/ lazr.restfulclient, thanks! I took the liberty of syncing it from exp
[06:29] <mlankhorst> morning
[07:40] <dholbach> good morning
[07:56] <LocutusOfBorg1> hi dear folks
[08:29] <ochosi> hey dholbach
[08:30] <dholbach> hi ochosi
[08:30] <ochosi> may i bug you for a sec?
[08:30] <dholbach> sure
[08:30] <ochosi> thanks!
[08:30] <ochosi> ok, so just quickly, because i'm going away over the weekend...
[08:30] <ochosi> since you approved the MR https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820
[08:30] <dholbach> I don't think I'm the best person to make a decision about this one
[08:31] <ochosi> i wanted to mention that we plan to SRU this to trusty, so it'd be great to get it into the archive soonish
[08:31] <ochosi> ah
[08:31] <dholbach> seb128, ^ do you think somebody on the desktop team can review this?
[08:31] <ochosi> right, i mean it's not too problematic, all in all it's just a shell script ;)
[08:31] <dholbach> well....
[08:31] <ochosi> but sure, if we need somebody else to review it, that's fine and good to know
[08:32] <seb128> dholbach, sure, I was sort of hopping that didrocks would get to it during his sponsoring shift on tuesday, but it seems that didn't happen there
[08:33] <ochosi> thanks seb128 (and dholbach)!
[08:33] <ochosi> since i'm going to be away for a week after today, i just felt like following up on a few things
[08:33] <didrocks> dholbach: yeah, I was quite busy yesterday, but as told early this morning to seb128, I'm going to shift with today (this afternoon, to be precise)
[08:34] <dholbach> yoohoo
[08:34] <seb128> didrocks, ok, letting it to you then, thanks ;-)
[08:35] <didrocks> yep :)
[08:35] <ochosi> didrocks: if there are any questions about it, feel free to bug me!
[08:35] <ochosi> at least today i should be aroundish
[08:39] <didrocks> ochosi: will do!
[08:39] <didrocks> thanks
[08:46] <mlankhorst> infinity: afaict word bounaries don't include hyphens, which are used in package names..
[08:49] <mlankhorst> meh weird.. dpkg-control looks like it should be smart enough
[08:50] <mlankhorst> hm, description, vcs-git and vcs-browser are unmodified, i should do the same for homepage then
[08:50] <mlankhorst> that was easy to fix..
[08:51] <mlankhorst> the reason it was renamed was because xf86-input-mtrack was in the mapping file, and I didn't special case homepage. Not because it was the source name.
[08:53] <mlankhorst> something like -lts-utopic-lts-utopic could never have happened on the debian/control file, because dpkg-control parses it
[08:56] <mlankhorst> -        elif 'Description' == prop or 'Vcs-Git' == prop or 'Vcs-Browser' == prop:
[08:56] <mlankhorst> +        elif 'Description' == prop or 'Vcs-Git' == prop or 'Vcs-Browser' == prop or 'Homepage' == prop:
[08:56] <mlankhorst>              print orig_line
[09:01] <cjwatson> prop.lower() in ("description", "vcs-git", "vcs-browser", "homepage")
[09:02] <cjwatson> you know it makes sense
[09:02] <mlankhorst> none of the affected packages have that :P
[09:02] <cjwatson> You can still make the code less repetitive :)
[09:03] <mlankhorst> it's code that runs once every 6 months, cost/effort analysis points to keep it like it is
[09:21] <Odd_Bloke> Hmph, removing /etc/machine-id doesn't seem to work: http://paste.ubuntu.com/9816701/
[09:21] <Odd_Bloke> (I'm switching to systemd by doing https://wiki.ubuntu.com/systemd#Installing_systemd without the PPA bit; is that correct?)
[09:51] <pitti> Odd_Bloke: please rather use https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems
[09:51] <pitti> Odd_Bloke: don't bother with trying this on anything < 14.10; on 14.10 you can experiment with systemd but there are lots of known failures especially on package upgrades
[09:51] <pitti> Odd_Bloke: it's only really supported on vivid
[09:52] <Odd_Bloke> pitti: OK, cool.
[09:54] <mlankhorst> huh?
[09:54] <mlankhorst> how did mesa build without llvm 3.5
[09:54] <mlankhorst> oh right, only on archs without llvm
[09:56] <pitti> Odd_Bloke: I added an outdated warning and a ref to the above page
[09:58] <Odd_Bloke> pitti: Thanks!
[10:08] <LocutusOfBorg1> pitti I feel stupid, but doesn't MoM grab the proposed stuff automatically?
[10:08] <LocutusOfBorg1> https://merges.ubuntu.com/s/samba/
[10:08] <LocutusOfBorg1> still listing ubuntu3
[10:08] <pitti> LocutusOfBorg1: it might be a bit behind; but indeed I don't believe it's looking at -proposed at all
[10:08] <LocutusOfBorg1> and I don't see it http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[10:08] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#samba
[10:08] <LocutusOfBorg1> what is blocking the migration?
[10:08] <pitti> ah, held by freeze
[10:09] <Laney> look at excuses first, then output
[10:09] <LocutusOfBorg1> ah, yes, the html page is more comphrensive
[10:09] <LocutusOfBorg1> so what should I do? just wait for -release, wait for MoM and ping you?
[10:12] <pitti> LocutusOfBorg1: or grab the diff from proposed and apply it to your merge
[10:12] <pitti> http://launchpadlibrarian.net/195481264/samba_2%3A4.1.11%2Bdfsg-1ubuntu3_2%3A4.1.11%2Bdfsg-1ubuntu4.diff.gz
[10:13] <pitti> dear LP developers, I love this feature
[10:13] <LocutusOfBorg1> mmm yes, but how? patch -p1 and resolve?
[10:13] <pitti> LocutusOfBorg1: pretty much, yes; there's a chance that the security fix is already applied in Debian, in which case it's only adding the new changelog
[10:14] <pitti> hm, no, it's not
[10:14] <pitti> or maybe it's fixed in 4.1.13 already?
[10:14] <LocutusOfBorg1> nope
[10:14] <LocutusOfBorg1> seems not fixed
[10:14] <LocutusOfBorg1> but I'm trying to apply right now
[10:14] <LocutusOfBorg1> at least in source.debian seems not applied
[10:15] <LocutusOfBorg1> https://sources.debian.net/src/samba/2:4.1.13%2Bdfsg-4/librpc/idl/security.idl/
[10:15] <LocutusOfBorg1> nope 4.1.13 is from 3 months ago
[10:15] <LocutusOfBorg1> the git commit id is from two days ago
[10:20] <LocutusOfBorg1> done!
[10:20] <LocutusOfBorg1> mail sent, can I forget about samba?
[10:20] <LocutusOfBorg1> looking to fix the 6 virtualbox CVEs now
[10:48] <Odd_Bloke> xnox: jamespage: So it looks like removing /etc/machine-id from the image makes systemd sad because /etc isn't writable when it wants to re-create it.
[10:48] <pitti> Odd_Bloke: you aren't using vivid, right?
[10:48] <pitti> Odd_Bloke: because that got fixed there
[10:49] <Odd_Bloke> pitti: "that" being /etc/machine-id being missing, or /etc not being writable?
[10:49] <pitti> Odd_Bloke: having a more clever mechanism to create /etc/machine-id, and write it to disk after it becomes writable
[10:49] <pitti> Odd_Bloke: i. e. "first boot" initi
[10:51] <Odd_Bloke> pitti: I am on vivid, but I'm looking at creating cloud images (which we build from scratch). How was the fix introduced?  (We might just have missed it)
[10:53] <pitti> Odd_Bloke: didrocks wrote a systemd-machine-id-setup helper (http://cgit.freedesktop.org/systemd/systemd/tree/src/core/machine-id-setup.c); at boot, systemd creates a tmpfs one while the root fs isn't writable yet, and then later on once it becomes writable that helper writes it to the root partition
[10:54] <pitti> didrocks: ^ BTW, you missed to put a correct copyright there :)
[10:55] <pitti> Odd_Bloke, didrocks: erk, sorry, wrong file: http://cgit.freedesktop.org/systemd/systemd/tree/src/machine-id-commit/machine-id-commit.c
[10:55] <pitti> Odd_Bloke: supposedly the cloud images shouldn't have a machine-id, it should be created on first boot?
[10:56] <abhinav_> Hey, I want to make some developmental contribution to ubuntu foundation. How should i get started?
[10:58] <Odd_Bloke> pitti: Yeah, we want to create it on first boot (otherwise all cloud instances will have the same machine-id).
[10:58] <pitti> Odd_Bloke: right, that's pretty much what we do on the desktop install images too
[10:58] <Odd_Bloke> pitti: So if /etc/machine-id is _empty_, we seem to be fine.
[10:58] <didrocks> Odd_Bloke: pitti: if the systemd is read-only at boot, you need still to have the file created, by empty
[10:58] <didrocks> so that you can machine-id-setup can mount it
[10:58] <Odd_Bloke> It's just if it's not present at all that we hit issues.
[10:58] <pitti> didrocks: I thought with that fix we wouldn't need an empty file any more?
[10:58] <didrocks> yeah
[10:59] <didrocks> pitti: we need to have it empty if the system is read-only
[10:59] <didrocks> however, the id is then committed once it's rw
[10:59] <didrocks> and you keep the same
[10:59] <didrocks> (which wasn't the case before)
[10:59] <pitti> didrocks: oh, I see -- to have a mountpoint
[10:59] <didrocks> exactly
[11:00] <xnox> didrocks: interesting. does it make it persistent?
[11:01] <didrocks> xnox: yeah, it does
[11:01]  * xnox is confused why systemd can't remount the fs rw without a machine-id....
[11:01] <xnox> it's not like firstboot is *that* interesting
[11:03] <xnox> oh, that's recent only been done in december...
[11:04] <jpds> abhinav_: Find something that interests you to hack on?
[11:04] <Odd_Bloke> xnox: You said something about writing an upstart job to create machine-id if missing; are we going to be supporting both upstart and systemd in vivid?
[11:05] <abhinav_> And from where to get that list of things to hack on?
[11:05] <Odd_Bloke> (Or, more generally, is there anywhere I can read a summary of the init system decisions/roadmap?)
[11:07] <pitti> Odd_Bloke: we don't want to support more than one init system in a release if we can help it
[11:07] <pitti> Odd_Bloke: that said, for vivid we might need to support upstart on the phone and systemd on desktop/server/cloud
[11:07] <pitti> Odd_Bloke: it depends on getting the remaining porting done: http://pad.ubuntu.com/systemd-porting-sprint
[11:08] <pitti> Odd_Bloke: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration is the current roadmap
[11:11] <xnox> Odd_Bloke: pitti: imho we need machine-id under upstart for the benefit of dropping dbus-machine-id and making the rest of things work correctly. E.g. doesn't logind under upstart need it? and things like that.
[11:11] <xnox> however I do hope that juju would be complete and we will be able to switch to systemd across the board
[11:12] <xnox> and possibly even the phone as well.
[11:14] <jpds> abhinav_: It's far easier if you go for something that already interests you.
[11:20] <abhinav_> jpds : and i m doing the same
[11:28] <jamespage> Odd_Bloke, do you want to assign the machine-id bug somewhere else other than nova?
[11:29] <Odd_Bloke> jamespage: Just posted a comment; nova should _potentially_ treat an empty machine-id the same way it does a missing one.
[11:30] <Odd_Bloke> jamespage: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1413293/comments/3
[11:45] <didrocks> @pilot in
[12:49] <LocutusOfBorg1> dholbach, FYI usually to create USB sticks I run dd
[12:50] <LocutusOfBorg1> the startup usb creator tool gives me always dbus errors
[12:50] <LocutusOfBorg1> :)
[12:50] <dholbach> right
[12:50] <LocutusOfBorg1> I like to keep it simple ;)
[14:45] <ochosi> didrocks: thanks a lot, didrocks! yeah, actually i did file a second MR but since brainwash did his MR on top of mine, both ended up in one...
[14:47] <didrocks> ochosi: yw ;) yeah, I saw that seb128 approved it, but didn't merge into the mainline
[14:47] <ochosi> indeed :)
[14:47] <didrocks> ochosi: thanks to you! uploaded now
[14:47] <ochosi> phew, now we can move one step further and go for SRU
[14:48] <ochosi> took us ages to realize how that problem of the screensaver timeout being reset happens and then to come up with the fix
[14:48] <ochosi> i guess 14.04 users will be happy about this...
[14:49] <didrocks> yeah, seems to have been complex to untangle :)
[14:49] <didrocks> nice work!
[14:49] <ochosi> thanks - and thanks again for the support!
[14:49] <didrocks> yw
[15:02] <LocutusOfBorg1> pitti, please let me know if you have troubles in the merge
[15:02] <LocutusOfBorg1> I'll open a bug instead :)
[15:03] <pitti> LocutusOfBorg1: I don't see it on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html ?
[15:03] <LocutusOfBorg1> nope I sent a mail privately
[15:03] <pitti> LocutusOfBorg1: hm, I didn't get any
[15:03] <pitti>  Subject: debdiff samba
[15:03] <pitti>   Folder: spam
[15:03] <pitti> LocutusOfBorg1: *blush* sorry ^
[15:04] <LocutusOfBorg1> +    + debian/patches/CVE-2014-8143.patch fix CVE-2014-8143.
[15:04] <LocutusOfBorg1> this is the last changelog line ;)
[15:04] <LocutusOfBorg1> just to be sure it isn't the same as yesterday!
[15:04] <LocutusOfBorg1> no problem pitti my fault
[15:04] <LocutusOfBorg1> I should write more verbose mail, to avoid spam
[15:05] <pitti> BAYES_80 and DNS_FROM_AHBL_RHSBL, that killed them, sorry
[15:09] <pitti> oh, the first second of vivid has been released :)
[15:09] <infinity> pitti: He corrected it in the u-d-a version. :)
[15:09] <pitti> infinity: ah, so the first was on u-release@ only, good
[15:10] <infinity> pitti: Note the subject line said A1 as well.
[15:10] <pitti> yeah, I wondered
[15:10] <infinity> pitti: Friends don't let friends email drunk.
[15:10] <pitti> he doesn't seem to be on IRC, for saying congrats?
[15:10] <infinity> pitti: He's in #-release
[15:22] <mejo> hi, can somebody with a recent ubuntu installation, encrypted root fs and upstart as init system do me a favour: please post the output of '/sbin/status cryptdisks-udev DEVNAME="<ROOTFS>"'.
[15:22] <mejo> I'm trying to fix a bug in cryptsetup but I don't have a ubuntu+upstart system at hand right now :-/
[15:50] <smoser> bug 1383794
[15:53] <LocutusOfBorg1> pitti, dholbach do you think one day I'll be ready to apply for becoming an ubuntu developer?
[15:53] <LocutusOfBorg1> https://nm.debian.org/public/process/locutusofborg
[15:53] <LocutusOfBorg1> the debian process is already started
[15:53] <dholbach> sure, you could already start putting together an application
[15:53] <dholbach> and ask your sponsors for some comments
[15:54] <dholbach> it'll give you an idea how ready you are
[15:54] <LocutusOfBorg1> should I become firstly a DD?
[15:54] <LocutusOfBorg1> to make the process easier?
[15:55] <pitti> LocutusOfBorg1: do you want me to fix little errors in your merge myself, or let you do another round for the learning experience?
[15:55] <pitti> (looking at samba)
[15:56] <LocutusOfBorg1> pitti, feel free to send a mail with the problems ;)
[15:57] <LocutusOfBorg1> or tell them here, as you wish
[16:01] <pitti> LocutusOfBorg1: sent
[16:01] <LocutusOfBorg1> thanks
[16:01] <LocutusOfBorg1> unfortunately the page doesn't mention DM, just DDs
[16:02] <LocutusOfBorg1> so I don't know how to best apply for a Per package upload
[16:07] <rbasak> Some Breaks/Replaces/Conflicts help please. I've read https://wiki.debian.org/PackageTransition carefully but not sure about this case.
[16:08] <rbasak> mysql-common-5.6 ships only /etc/mysql/conf.d/my5.6.cnf, and apart from comments it's actually empty (but may have user modifications).
[16:08] <rbasak> In my next upload, I'm getting rid of this binary package. mysql-common will supply /etc/mysql/conf.d/, and mysql-server-5.6 will supply server-specific configuration, including for 5.6, but not at the previous path.
[16:09] <rbasak> Right now, in my testing, everything is fine and mysql-common-5.6 is suggested by apt for autoremoval.
[16:09] <rbasak> Is this fine, or should the new mysql-common declare Breaks against mysql-common-5.6 (<< new) to force mysql-common-5.6 to be removed?
[16:10] <rbasak> Not that this makes much difference, because the old file is a conffile and so will remain until purge, but it might help to indicate that it's no longer necessary.
[16:10] <rbasak> Alternatively, maybe mysql-common Breaks+Replaces+Conflicts mysql-common-5.6 (<< new) to actually force the old package to disappear? I don't see this usage in PackageTransition though.
[16:10] <rbasak> EOquesiton
[16:12] <LocutusOfBorg1> thanks pitti mail sent :)
[16:14] <pitti> rbasak: unless m-common actually ships a /etc/mysql/conf.d/my5.6.cnf there shouldn't be an acutal file conflict, or am I missing something?
[16:15] <pitti> rbasak: what you could do is to add a .maintscript snippet to clean up the obsolete conffile on upgrades (to m-common)
[16:15] <rbasak> pitti: yeah there's no actual file conflict. It'd be nice to clean up the old package though.
[16:15] <pitti> rbasak: as it's comment-only it's not like it would actually hurt, but if you want to be clean :)
[16:16] <pitti> rbasak: oh, for that; yes, Conflicts:/Provides: is your friend there
[16:16] <rbasak> pitti: I'm not sure this counts as an obsolete conffile though. It just needs a purge of mysql-common-5.6, which the user can choose to do (or not).
[16:16] <pitti> rbasak: Conflicts: for removing it, and Provides: for nudging apt that it's okay to do that instead of holding back the upgrade
[16:16] <pitti> rbasak: yes, true that, so ignore that bit
[16:17] <pitti> rbasak: but Breaks: mysql-common-5.6 (<< new) wouldn't be right as there is no "new"
[16:17] <pitti> rbasak: if you actually want to replace an entire package, then Conflicts: is right (as per policy)
[16:17] <pitti> rbasak: https://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2
[16:17] <rbasak> pitti: so Conflicts: mysql-common-5.6 and Provides: mysql-common-5.6?
[16:18] <pitti> rbasak: ah, and I forgot Replaces:
[16:18] <rbasak> pitti: OK. So all three, unversioned?
[16:19] <pitti> rbasak: yes, that's the standard approach; Provides: *might* not be necessary, but often it is and it doesn't hurt
[16:19] <rbasak> pitti: OK. Thanks!
[16:19] <pitti> (wrt. nudging apt)
[16:21] <rbasak> pitti: so I have a similar problem in that the mysql-server package that previously depended on mysql-server-5.5 now depends on mysql-server-5.6, and apt wants to resolve the dist-upgrade by removing mysql-server.
[16:22] <rbasak> pitti: is this another case that I can fix by having mysql-server-5.6 provide+conflict+replace mysql-server-5.5? We'll be removing 5.5 this cycle if that's relevant.
[16:22] <pitti> rbasak: if -5.5 goes away, then that sounds right
[16:23] <pitti> rbasak: assuming that -5.6 just takes over an existing database?
[16:23] <pitti> rbasak: but if that happens that means that -5.6 conflicts with -5.5 already?
[16:23]  * rbasak checks
[16:23] <pitti> Replaces: mysql-server-5.5, virtual-mysql-server
[16:23] <pitti> Provides: virtual-mysql-server
[16:24] <pitti> Breaks: mysql-server-5.5, virtual-mysql-server
[16:24] <rbasak> Yeah
[16:24] <pitti> yeah, that doesn't look quite right; unversioned Breaks: are not well defined
[16:24] <pitti> rbasak: so changing that to C/R/P: -5.5 should work better
[16:24] <rbasak> pitti: OK. Thanks!
[16:24] <pitti> rbasak: if semantically -5.6 takes over an existing db and just continues working, of course
[16:24] <rbasak> Yes, that's correct.
[16:24] <pitti> rbasak: if that's not the case, then the upgrade should just be aborted
[16:24] <pitti> ok, good
[16:25] <rbasak> Thank you for your help. I'll try this and test.
[16:25] <pitti> cheers
[16:26] <pitti> rbasak: and yes, the above is exactly the kind of nudging that apt needs :)
[16:26] <pitti> rbasak: it's rather hesitant to uninstall packages; there must be several packages depending on the replacing one until their score becomes higher than the removal penalty
[16:27] <pitti> therefore Provides:, which removes that
[16:27]  * pitti is sure that mvo can explain this a lot better
[16:28] <pitti> rbasak: OOI, do they actually never change their on-disk format, or do newer versions just convert it on the fly?
[16:28] <rbasak> pitti: yeah - the dependency tree is a little altered now. I think that's swinging the balance a little the wrong way. Hopefully C/R/P will fix it.
[16:28] <pitti> IOW, once you ran 5.6, could you go back to 5.5?
[16:28] <rbasak> I'm not sure. I'd need to check with upstream.
[16:29] <rbasak> I think it'll refuse to let you and fail the maintainer script after a critical debconf prompt.
[16:29] <rbasak> Or at least that's what we resolved it should do.
[16:33] <didrocks> @pilot out
[16:42] <pitti> LocutusOfBorg1: hm, now you entirely dropped the logrotate changelog entry?
[16:43] <bdmurray> pitti: I'm curious about the decision not to run package hooks on the phone. Was it because Errors didn't accept all fields or for performance reasons?
[16:44] <LocutusOfBorg1> yes, sorry
[16:44] <LocutusOfBorg1> my bad
[16:45] <pitti> LocutusOfBorg1: replied
[16:46] <LocutusOfBorg1> thanks
[16:48] <teward> random question: is it possible to configure a system to have something init at boot time *after* some other process?
[16:48] <teward> s/process/process does/
[16:48] <infinity> rbasak: It shouldn't provide 5.5, that's a lie.  Just C/R.
[16:49] <infinity> rbasak: C/R is the magic that tells apt "prefer this one over the other one".
[16:49] <infinity> rbasak: Which you do with virtual-mysql-server
[16:50] <LocutusOfBorg1> pitti, "debian/samba.logrotate: use systemd to restart smbd service."
[16:50] <LocutusOfBorg1> do you like it?
[16:50] <teward> s/a system/an init script for a given package/
[16:50] <pitti> LocutusOfBorg1: no, not systemd -- "service" :)
[16:50]  * teward fails at typing apparently.
[16:50] <LocutusOfBorg1>     + debian/samba.logrotate: use service to restart smbd.
[16:51] <LocutusOfBorg1> maybe "service"
[16:51] <pitti> LocutusOfBorg1: I'd keep xnox' original rationale, too: such that it works under both upstart and systemd.
[16:51] <pitti> LocutusOfBorg1: the point of the changelog is not to say *what* changed -- that's obvious from the diff; it should give a rationale why it changed
[16:51] <infinity> pitti: MySQL upstream changes the formats occasionally, but newer versions are smart enough to be able to upgrade formats on the fly during a DB fsck, which happens on first run.
[16:51] <pitti> +    + debian/samba-common.config:
[16:51] <pitti> +      - Do not change prioritiy to high if dhclient3 is installed.
[16:52] <pitti> e. g. that -- that still doesn't give a rationale, just descibes the patch in English
[16:52] <pitti> infinity: ah, so you couldn't go back anyway, and indeed the packages shoudln't be co-installable or have a Provides:
[16:52] <infinity> pitti: Right.
[16:53] <infinity> pitti: Well, you might be able to downgrade from 5.6 to 5.5, I don't know, but it's not a given that you can.
[16:54] <bdmurray> jamespage: last week you'd suggested rejecting heat from the utopic -proposed queue but were going to double check IIRC. Should I reject it now?
[16:55] <LocutusOfBorg1> damn pitti now I got the problem
[16:55] <LocutusOfBorg1> I was looking at the wrong line
[16:55] <LocutusOfBorg1> :(
[16:55] <LocutusOfBorg1> sorry
[16:56] <rbasak> infinity: http://paste.ubuntu.com/9821906/ is what I have right now, and it doesn't work. Test in ppa:mysql-ubuntu/collab. Installing mysql-server from the archive, and then dist-upgrade with the PPA enabled, and apt wants to remove mysql-server.
[16:56] <LocutusOfBorg1>     + debian/samba.logrotate: use service command to reload (send SIGHUP) the main
[16:56] <LocutusOfBorg1>       processes such that it works under both upstart and systemd.
[16:56] <rbasak> infinity: the only difference I see is that instead of Conflicts, I have Breaks.
[16:56] <infinity> rbasak: Those Breaks don't belong.
[16:57] <infinity> rbasak: Breaks/Replaces means "overwrite some files, yo".  Conflicts/Replaces means "I'm better than this package, nya nya".
[16:57] <infinity> rbasak: If your Breaks/Replaces is unversioned, you know you've done something wrong.
[16:57] <rbasak> infinity: OK, so I'll switch a bunch of the breaks to conflicts. Thans.
[16:59] <infinity> rbasak: Basically, think of it like this:
[16:59] <infinity> rbasak: Breaks: I don't get along with some versions of this package (should always be versioned)
[16:59] <infinity> rbasak: Conflicts: I don't get along with this package at all, and probably never will, it's a jerk.
[16:59] <infinity> rbasak: Replaces: Overwrite files from the other package.
[17:00] <infinity> rbasak: Conflicts/Replaces: the logical union of the two, ie: overwrite the whole package, prefer me, I'm SPECIAL!
[17:00] <infinity> rbasak: Breaks/Replaces (versioned pair): overwrite files that belong to the package version I don't like, but leave new ones alone.
[17:01] <rbasak> infinity: thanks.
[17:01] <infinity> rbasak: And P/C/R is a logical union of C/R and P, in that you claim to basically BE the same package entirely.  P/C/R sets are usually found mutually between packages, but sometimes also used to transition between names.
[17:01] <rbasak> I more or less got that, but some of the special cases aren't completely obvious to me on the wiki
[17:02] <infinity> rbasak: In your case, mysql-5.6 really isn't mysql-5.5, so a provides would be a lie (on the off chance someone really does need to depend on the exact version), but C/R seems sane, and should hint apt to DTRT.
[17:02] <infinity> rbasak: If it doesn't, yell, cause I'm curious.
[17:02] <infinity> rbasak: Yell later, though, I'm off to bed in a bit.
[17:03] <rbasak> infinity: the awkward thing here are the binary versioned packages I think. Both mysql 5.6 and mysql 5.5 exist concurrently in multiple releases now. So whether it's a transition depends on how you look at it.
[17:03] <rbasak> The wiki's wording sort of assumes that you'll be making a change entirely in one release.
[17:07] <infinity> rbasak: They can't coexist, it's still right for the newer ones to C/R the older ones.
[17:07] <infinity> rbasak: And that should make the metapackage transition smooth.
[17:08] <rbasak> OK
[17:59] <rbasak> infinity: using Conflicts didn't fix it. It still wants to remove mysql-server.
[17:59] <rbasak> infinity: http://paste.ubuntu.com/9822731/
[17:59] <rbasak> infinity: http://paste.ubuntu.com/9822739/
[18:02] <rbasak> infinity: OTOH, if I remove vivid from sources.list and just have my test PPA, then apt is happy to upgrade as expected.
[18:02] <rbasak> infinity: this is exactly what happened last cycle, and why I asked for the two to be done close together in time to avoid people following vivid from failing to follow the upgrade.
[18:02] <rbasak> infinity: and you said that was broken and you wanted to dig deeper :)
[18:34] <jamespage> bdmurray, +1 please reject
[20:16] <rsalveti> doko: any idea why the bins produced by gcc-go are also using the multiarch env in the path? It seems instead of /usr/bin/test, it got installed as /usr/bin/DEB_HOST_ARCH/test, but only on ppc64el
[20:16] <rsalveti> sergiusens: ^
[20:17] <rsalveti> this made nuntium to ftbfs only on ppc64el: https://launchpadlibrarian.net/195549654/buildlog_ubuntu-vivid-ppc64el.nuntium_1.4-0ubuntu1_FAILEDTOBUILD.txt.gz
[20:17] <rsalveti> sergiusens: once we know a bit more about the problem we can get the fix in place
[20:18] <sergiusens> rsalveti: it's fine for now; no more hurries as I got permission to push to ubuntu-rtm
[20:21] <rsalveti> right
[22:22] <slangasek> why does firefox keep showing me the Ubuntu start page in Arabic instead of English?
[22:23] <sarnold> slangasek: I think chrisccoulson mentioned it makes the decision based in part on the timezone you're using
[22:25] <mdeslaur> slangasek: so you can learn Arabic :)
[22:25] <chrisccoulson> That would be a question for someone like beuno. I'm not sure how the start page determines your locale (I guess it's using the Accept-Language header)
[22:25] <chrisccoulson> But a few people have pinged me about similar issues in recent days
[22:25] <chrisccoulson> mdeslaur, didn't you have the same issue?
[22:26] <slangasek> sarnold: ah I knew I shouldn't have picked Europe/No-Go-Zone
[22:26] <mdeslaur> yeah, mine was coming up in czech
[22:26] <slangasek> chrisccoulson: ar isn't in my Accept-Language header
[22:26] <chrisccoulson> slangasek, which would suggest a server-side issue
[22:27] <slangasek> mdeslaur: krásný
[22:27] <slangasek> chrisccoulson: righto.  It's also intermittent and only affects the title bar, not the page content
[22:28] <mdeslaur> slangasek: oh? the text beside the icons was translated for me
[22:28] <mdeslaur> "Ubuntu help", "Ubuntu shop", etc.
[22:28] <slangasek> I don't think it was here, but can't reproduce now
[22:31] <chrisccoulson> slangasek, I'd probably report a bug against ubuntu-start-page. Particularly if it's not happening with other sites (eg, Google when you're not logged in)
[22:33] <slangasek> chrisccoulson: right.  will do if I manage to reproduce it again, maybe it's cleared up
[22:55] <doko> rsalveti, sergiusens: ENOCLUE. I'm not familiar with nuntium. can you file a bug report with more details? (yeah for debhelper for not printing how the upstream build system is called)
[23:26] <eltigre> The current documentation on Ubuntu Core seems to have one slight drawback: Ubuntu Core is said to be built for docker, but the pages don't explain how to use docker on ubuntu core