=== NCommand` is now known as NCommander
=== NCommander is now known as Guest84161
[00:34] <bdmurray> slangasek: I've uploaded xorg and update-manager changes for fglrx and hwe support
[00:42] <slangasek> bdmurray: \o/ thanks
[07:33] <acheronuk> do daily isos stop building after so many failures? e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/kubuntu
[07:37] <jbicha> acheronuk: I tried asking in #kubuntu-devel this weekend for someone to try to rebuild the yakkety iso since it might work now (the kactivities binary has been removed)
[07:37] <tsimonq2> jbicha: that's what we're trying to get done now ;)
[07:37] <cjwatson> There's nothing automatic that stops image builds after failures.
[07:38] <tsimonq2> oh, weird
[07:38] <cjwatson> But the Kubuntu image build is commented out of the crontab for some reason.
[07:38] <tsimonq2> could someone rebuild Kubuntu Yakkety then?
[07:39] <cjwatson> I've uncommented it and started a build.
[07:39] <tsimonq2> ahh, so a member of the release team might have done that
[07:39] <tsimonq2> thanks so much cjwatson! :)
[07:39] <tsimonq2> acheronuk: ^
[07:39] <cjwatson> Could have been an accident when dealing with disabled builds around the beta.
[07:39] <acheronuk> jbicha: yes I saw that. yofl is snowed under with other commitments I think, so proably didn't see it
[07:41] <acheronuk> may still fail, but would be nice to give it a poke and see now kactivities is gone
[07:42] <cjwatson> Yep.
[07:42] <cjwatson> Should be on automatic as usual now, anyway.
[07:42] <acheronuk> thank you :)
[07:42] <cjwatson> np
=== ochosi_ is now known as ochosi
[07:44] <jbicha> cjwatson: since we already missed today's run, do you want to run a kubuntu iso rebuild now?
[07:45] <cjwatson> jbicha: 08:39 <cjwatson> I've uncommented it and started a build.
[07:45] <jbicha> thanks
[07:48]  * acheronuk crosses everything it works
[07:53] <acheronuk> BTW, are these the build scripts? http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/files
[07:56] <cjwatson> That's part of them, but debian-cd is mostly not very interesting for live-CD-type builds.
[07:57] <cjwatson> The top level is lp:ubuntu-cdimage, but most of the actual live filesystem content is constructed by the livecd-rootfs and live-build packages.
[07:57] <cjwatson> (lp:ubuntu-cdimage is mainly coordination and publishing)
[07:59] <acheronuk> ah. ok. thanks
[08:08] <acheronuk> that seemed to build :D
=== happyaro1 is now known as happyaron
=== ant_ is now known as Guest58751
=== Guest84161 is now known as NCommander
=== NCommander is now known as Guest43443
[14:50] <barry> release team, can i get a rubber stamp for LP: #1617007 ?
[14:50] <ubot5> Launchpad bug 1617007 in twine (Ubuntu) "[FFE] twine 1.8.1-1" [Undecided,New] https://launchpad.net/bugs/1617007
[15:26] <apw> ^ /me is on that ...
[15:46] <bdmurray> slangasek: Could you review the update-manager / xorg-server-lts-xenial uploads in the Trusty queue?
[15:49] <robru> xnox: if you're still about can you take a look at my reply to your review of my branch? thanks
[15:56] <slangasek> bdmurray: looking
[16:03] <xnox> weird, i didn't get an email.
[16:09] <robru> xnox: oh I replied to the email I got
[16:10] <robru> xnox: my reply went through lp
[16:31] <xnox> robru, lp is slow =) finally got your email. responded on launchpad instead.
[16:32] <xnox> robru, the order of how things are cloned and merged matters a lot....
[16:32] <xnox> ideally one should fetch/reset to project's master branch first
[16:32] <xnox> and then from there call: merge lp:proposed-repo proposed-fix-branch
[16:32] <xnox> instead of reverse. See my further comments.
[17:16] <slangasek> bdmurray: accepted, thanks
=== Guest43443 is now known as NCommander
[18:36] <robru> xnox: slangasek: what's the git equivalent of bzr-builddeb, specifically the part that allows it to merge debian/changelog without conflicts?
[18:38] <slangasek> robru: 'dpkg-mergechangelogs'
[18:38] <xnox> robru, i have a thing for you sir!
[18:38] <xnox> robru, "just" specify
[18:38] <xnox> [merge "dpkg-mergechangelogs"]
[18:38] <xnox>         name = debian/changelog merge driver
[18:38] <xnox>         driver = dpkg-mergechangelogs -m %O %A %B %A
[18:38] <slangasek> (which is the underlying implementation in bzr-builddeb's implementation also)
[18:38] <xnox> in ~/.gitconfig
[18:39] <xnox> and then there is more
[18:39] <robru> xnox: slangasek: great, thanks
[18:39] <xnox> $ cat ~/.config/git/attributes
[18:39] <xnox> debian/changelog merge=dpkg-mergechangelogs
[18:39] <xnox> together first thing creates a merge strategy
[18:39] <xnox> the second thing sets a "global" (XDG_BASE_DIR location) attribute to change git behaviour for files that match that pattern in any repository
[18:41] <robru> xnox: what do you mean "any repository"? what repositories will not be handled by the global gitconfig?
[18:42] <xnox> robru, ~/.gitconfig creates a merge strategy, and no files use it.
[18:43] <xnox> robru, ~/.config/git/attributes sets the attribute for any repositories that this user will operate on. "Usually" attributes in git are set on per repository basis in .git/info/attributes and thus don't propagate across clones at all.
[18:43] <xnox> "usually" attributes are used on windows systems to specify line-endings conversions and some such stuff.
[18:43] <robru> xnox: ah
[18:43] <xnox> dpkg-mergechangelogs is "weird"
[18:45] <robru> xnox: will git know to look in ~/.config if no $XDG_* variables are set? this is not running as an interactive user
[18:45] <robru> xnox: better question, where does git look for global attributes when no $XDG_* vars are set ;-)
[18:47] <robru> xnox: nm, "If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/attributes is used instead."
[18:49] <xnox> robru, yes... XDG spec says to try $HOME/.config if e.g. XDG_CONFIG_HOME is not set.
[18:50] <xnox> that's why XDG base dir spec is good.
[18:54] <robru> xnox: hm, not working, any ideas here: http://paste.ubuntu.com/23113050/ ?
[18:56] <xnox> robru, ok, and what users runs git? and is the home for that user in /var/www ?
[18:56]  * xnox checks my configs more
[18:56] <robru> xnox: yes, www-data is running git, and /var/www is $HOME
[18:56] <robru> I'll try to reproduce locally, maybe it's a real conflict
[18:58] <xnox> robru, $ sudo apt install dpkg-dev ?
[19:00] <robru> xnox: already installed
[19:00] <xnox> robru, check permissions on those files too... should be owned by www-data.
[19:00]  * xnox tries to find a way to validate which attributes are applied for a file
[19:01] <xnox> $ git check-attr --all debian/changelog
[19:01] <xnox> debian/changelog: merge: dpkg-mergechangelogs
[19:01] <robru> xnox: this may be a legitimate conflict, these changelogs were both done by hand so it's not clear to me that this is quite what mergechangelogs was meant for: http://paste.ubuntu.com/23113075/
[19:02] <xnox> horum. yeah.
[19:02] <xnox> quick way to check that dpkg-mergechangelogs work is to "merge" a git-import-dsc "commit"
[19:03] <xnox> or run the check-attr command.
[19:03] <xnox> if that shows as enabled for debian/changelog, then all is good, and one should get less merge conflicts.
[19:03] <robru> xnox: oh I see, it's trying to merge two different entries with the same version number, that's why
[19:03] <xnox> robru, which means that dpkg-mergechangelogs is doing something, and trying to be helpful.
[19:03] <xnox> possibly
[19:04] <robru> xnox: ok thanks, yeah I think everything is good, just bad example to test with
[19:04]  * xnox wonders if launchpad has dpkg-mergechangelogs setup
[19:04] <xnox> for git
[20:23] <cjwatson> xnox: it does not, but it would at most only matter for merge previews
[20:23] <cjwatson> xnox: and arguably setting it up for those would be misleading, because it would mean an apparently conflict-free merge would only be conflict-free if you happened to have dpkg-mergechangelogs set up
[20:24] <xnox> true, yet it would be so nice.
[20:24] <xnox> to be honest, i'm failing to see why debian/ubuntu does not ship that enabled globally by default.
[20:24] <xnox> it would be easy enough to do.