| === NCommand` is now known as NCommander | ||
| === NCommander is now known as Guest84161 | ||
| bdmurray | slangasek: I've uploaded xorg and update-manager changes for fglrx and hwe support | 00:34 |
|---|---|---|
| slangasek | bdmurray: \o/ thanks | 00:42 |
| acheronuk | do daily isos stop building after so many failures? e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/kubuntu | 07:33 |
| 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:37 |
| 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:38 |
| 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:39 |
| acheronuk | may still fail, but would be nice to give it a poke and see now kactivities is gone | 07:41 |
| cjwatson | Yep. | 07:42 |
| cjwatson | Should be on automatic as usual now, anyway. | 07:42 |
| acheronuk | thank you :) | 07:42 |
| cjwatson | np | 07:42 |
| === ochosi_ is now known as ochosi | ||
| jbicha | cjwatson: since we already missed today's run, do you want to run a kubuntu iso rebuild now? | 07:44 |
| cjwatson | jbicha: 08:39 <cjwatson> I've uncommented it and started a build. | 07:45 |
| jbicha | thanks | 07:45 |
| * acheronuk crosses everything it works | 07:48 | |
| acheronuk | BTW, are these the build scripts? http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/files | 07:53 |
| cjwatson | That's part of them, but debian-cd is mostly not very interesting for live-CD-type builds. | 07:56 |
| 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:57 |
| acheronuk | ah. ok. thanks | 07:59 |
| acheronuk | that seemed to build :D | 08:08 |
| === happyaro1 is now known as happyaron | ||
| === ant_ is now known as Guest58751 | ||
| === Guest84161 is now known as NCommander | ||
| === NCommander is now known as Guest43443 | ||
| 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 | 14:50 |
| apw | ^ /me is on that ... | 15:26 |
| bdmurray | slangasek: Could you review the update-manager / xorg-server-lts-xenial uploads in the Trusty queue? | 15:46 |
| robru | xnox: if you're still about can you take a look at my reply to your review of my branch? thanks | 15:49 |
| slangasek | bdmurray: looking | 15:56 |
| xnox | weird, i didn't get an email. | 16:03 |
| robru | xnox: oh I replied to the email I got | 16:09 |
| robru | xnox: my reply went through lp | 16:10 |
| xnox | robru, lp is slow =) finally got your email. responded on launchpad instead. | 16:31 |
| 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. | 16:32 |
| slangasek | bdmurray: accepted, thanks | 17:16 |
| === Guest43443 is now known as NCommander | ||
| robru | xnox: slangasek: what's the git equivalent of bzr-builddeb, specifically the part that allows it to merge debian/changelog without conflicts? | 18:36 |
| 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:38 |
| 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:39 |
| robru | xnox: what do you mean "any repository"? what repositories will not be handled by the global gitconfig? | 18:41 |
| xnox | robru, ~/.gitconfig creates a merge strategy, and no files use it. | 18:42 |
| 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:43 |
| 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:45 |
| robru | xnox: nm, "If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/attributes is used instead." | 18:47 |
| xnox | robru, yes... XDG spec says to try $HOME/.config if e.g. XDG_CONFIG_HOME is not set. | 18:49 |
| xnox | that's why XDG base dir spec is good. | 18:50 |
| robru | xnox: hm, not working, any ideas here: http://paste.ubuntu.com/23113050/ ? | 18:54 |
| 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:56 |
| xnox | robru, $ sudo apt install dpkg-dev ? | 18:58 |
| 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:00 | |
| 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:01 |
| xnox | horum. yeah. | 19:02 |
| xnox | quick way to check that dpkg-mergechangelogs work is to "merge" a git-import-dsc "commit" | 19:02 |
| 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:03 |
| 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 | 19:04 |
| 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:23 |
| 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. | 20:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!