[00:43] <TheMuso> pitti: I'm happy to take care of the brltty merge if you haven't already started it.
[05:44] <pitti> Good morning
[05:44] <pitti> TheMuso: I didn't start yet; thanks!
[05:50] <TheMuso> pitti: np
[06:20] <pitti> cyphermox: FYI, new isc-dhcp is held in -proposed by regresssing NetworkManager test
[06:21] <pitti> cyphermox: it seems something is now spilling "Killed old client process" to stderr -- leftover debug message which shoudl be quiesced again?
[06:21] <pitti> or something which we need to ignore in the tests?
[07:38] <dholbach> good morning
[08:23] <Saviq> pitti, hey, I wanted to confirm something... now that we have separate rtm branches/series in some projects (like unity8 and friends), what happens to the translations/langpacks? should we bring the translation updates from trunk into the rtm branches? or should we enable translations for the rtm series and rely on the translations being shared?
[08:49] <pitti> Saviq: yes, translations for RTM need to be enabled, but they are at the distro level (not project)
[08:49] <pitti> Saviq: through message sharing that works, we build RTM specific langpacks
[08:49] <pitti> Saviq: the main (and crucial!) thing to do is that a package build builds an up-to-date .pot
[08:49] <Saviq> pitti, of course
[08:50] <Saviq> pitti, so, in the case of unity8, we only have project-level translations right now
[08:50] <Saviq> pitti, what should we do to make this happen for rtm?
[08:52] <pitti> Saviq: seems quite alright? https://translations.launchpad.net/ubuntu-rtm/14.09/+source/unity8/+pots/unity8
[08:53] <Noskcaj> dholbach, Fixing webtest now, sorry for screwup
[08:53] <Saviq> pitti, hmm, right, but nothing syncs to the series http://bazaar.launchpad.net/~unity-team/unity8/rtm-14.09/changes
[08:54] <pitti> Saviq: I'm confused -- what do you need synced to the RTM branch?
[08:54] <Saviq> pitti, the .po file changes?
[08:55] <Saviq> pitti, like in trunk we're getting http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1431
[08:56] <pitti> Saviq: well, you can import them if you like, but they don't get into the .deb anyway
[08:56] <pitti> Saviq: as I said, the crucial thing is an up to date .pot, then LP message sharing will DTRT
[08:56] <Saviq> pitti, ah so the actual langpacks get generated straight out of LP?
[08:56] <pitti> right
[08:56] <Saviq> ok, that's what I was missing
[08:56] <Saviq> pitti, thanks, that explains things then
[08:57] <pitti> Saviq: did you spot anything wrong/missing there?
[08:57] <Saviq> pitti, no, just got scared we're not doing something we should be doing
[09:05] <tvoss> pitti, good morning
[09:07] <pitti> hey tvoss
[11:17] <ogra_> dpm, how do i get my http://summit.ubuntu.com/uos-1411/ogra/meetings onto the schedule ?
[11:24] <dpm> ogra_, track leads should be approving the sessions. You might need to ping them. For the development track, they are: Will Cooke, Łukasz Zemczak, Steve Langasek, Antonio Rosales, and Rohan Garg
[11:25] <ogra_> ok
[12:05] <ogra_> willcooke, ^^^ could you approve my sessions ?
[12:06] <willcooke> ogra_, there's something wrong with my set up in summit, waiting on mhall119 to come online and fix it
[12:06] <ogra_> oki
[13:40] <mhall119> willcooke: let me check
[13:40] <willcooke> mhall119, thx
[13:41] <mhall119> willcooke: there's nothing waiting to be scheduled on the Ubuntu Development track
[13:41] <willcooke> ogra_, ^^^
[13:41] <mhall119> willcooke: you have some you can review on http://summit.ubuntu.com/uos-1411/review/
[13:42] <willcooke> mhall119, that URL doesn't show me anything to review
[13:42] <ogra_> mhall119, so how do i get http://summit.ubuntu.com/uos-1411/ogra/meetings into some review/approval queue
[13:42] <mhall119> willcooke: then there might be something wrong with your account
[13:43] <mhall119> willcooke: at the top, where is says "Logged in as:" what username is displayed?
[13:43] <willcooke> mhall119, logged in as willcooke (and that links to my LP page)
[13:44] <mhall119> hmmm....
[13:44] <mhall119> ogra_: they're already in one, but something's wrong with will's account
[13:45] <ogra_> ah, its all willcooke's fault then, ok
[13:45]  * ogra_ knew it
[13:45] <mdeslaur> bdmurray: mind if I steal your curl merge?
[13:45] <willcooke> ogra_, :)  typical
[13:45] <ogra_> :)
[13:52] <mhall119> shadeslayer: can you see any session pending review on http://summit.ubuntu.com/uos-1411/review/ ?
[13:59] <mhall119> willcooke: well popey can he stuff for his track, so it must be just you that's broken, try logging out and back in
[14:00] <willcooke> mhall119, ok :)
[14:00] <willcooke> mhall119, sam,e
[14:00] <willcooke> same
[14:01] <shadeslayer> mhall119: looking
[14:01] <shadeslayer> mhall119: there's a few
[14:03] <mhall119> well willcooke....what have you done to summit?
[14:03] <mhall119> oh, wait.....
[14:04] <mhall119> I did it :)
[14:04] <willcooke> mhall119, erm - it was like that when I got here?
[14:04] <mhall119> willcooke: try that page again
[14:05] <willcooke> mhall119, ooooooohhhh  - suddenly everything is different
[14:06] <mhall119> now you can approve ogra_'s sessions :)
[14:06] <cyphermox> pitti: perhaps. I'll take a look
[14:06] <ogra_> \o/
[14:06] <willcooke> I'll have to re-read the instructions
[14:08] <cjwatson> doko: I think gluegen2 can be synced; your diff to it was to build with the zero VM on arm64 because it previously failed to build, but the latest version of gluegen2 built cleanly on Debian arm64 so it looks likely to be fine now.  Are you OK with that?
[14:08] <ogra_> mdeslaur, pitti, i remember there was a reason why we didnt include dbus 1.6,.18 but kept .16 in rtm ...
[14:09] <ogra_> mdeslaur, pitti do you guys remember what that was ? ricmm thinnks this could be related to our multiple hangs and CPU at 100% thins
[14:09] <ogra_> *thigs
[14:09] <mdeslaur> ogra_: bug 1362469
[14:10] <pitti> ogra_: I'm afraid I wasn't involved in that discussion
[14:10] <pitti> ah, there we go, thanks mdeslaur
[14:10] <ogra_> pitti, yeah, i just remembered one of you two was
[14:11] <mdeslaur> ogra_: perhaps tyhicks made some progress investigating that
[14:12] <mdeslaur> tyhicks: pingy ping ping
[14:39] <mdeslaur> bdmurray: too late :P
[14:55] <cjwatson> doko: Went ahead and synced gluegen2, since it's blocking something else I need.  We can always put back the diff if it's a problem.
[15:22] <tyhicks> ogra_: the 1.6.18 merge came in pretty late for utopic so I didn't push to include it in rtm and then we found bug 1362469 so we decided to definitely not push for it in rtm
[15:23] <tyhicks> ogra_: I've looked at that bug quite a bit but haven't been able to make good progress
[15:23] <tyhicks> ogra_: it is about as difficult to debug as the cpu pinning bug that others are trying to solve :/
[15:26] <ogra_> thywell, ricmm suspects the CPU peging is caused by us being behind in dbus versions on rtm
[15:26] <ogra_> tyhicks, ^^^^
[15:28] <tyhicks> ogra_: has anyone been able to verify that 1.6.18 fixes the cpu peging?
[15:28] <ogra_> i doubt that ... talk to ricmm (who is in a meetign atm)
[15:29] <tyhicks> ok
[15:29] <xnox> lamont: it's all in ubiquity/frontend/gtk_ui.py the vte bits, it shouldn't be that many.
[15:29] <xnox> lamont: unping
[15:29] <xnox> Laney: ^
[15:29] <Laney> xnox: I see it - that's for the debugging mode?
[15:30] <xnox> Laney: it's present and running at all times, on all gtk frontends, however most of the time it's invisible. But widget is initiated as is there.
[15:30] <tyhicks> ogra_, ricmm: at this point in the rtm schedule, I'd be far more comfortable backporting the specific fix for the cpu pegging bug from 1.6.18 to 1.6.16 and I'll work on fixing bug 1362469 in the meantime
[15:31] <xnox> Laney: UI wise, it's accessible after one starts the installation (after clicking next in partitioning), however progress dots are in the way to actually expand it to show it.
[15:31] <ogra_> tyhicks, right, i think ricmm also meant he had seen only some specific things in the changelog that could be related, but we indeed need to make out if thats actually helping
[15:31] <xnox> Laney: what's changed in vte? it's only one vte specific command and the rest are regular gtk+ calls/functions.
[15:34] <Laney> xnox: so this /is/ the expandered vte?
[15:35] <Laney> I misremembered that this showed the usual debug output like update-manager does
[15:35] <Laney> there's some random API cleanups
[15:36] <xnox> Laney: yes. and there is nothing else vte in ubiquity.
[15:37] <Laney> cool
[15:37] <Laney> I thought there were two things when you talked about debug-ubiquity
[15:37] <xnox> Laney: ctl-alt-t thing in debug mode simply launches the default terminal, as in it launches gnome-terminal
[15:37] <Laney> Right, nothing to worry about here then
[15:37] <xnox> Laney: so ubiquity vte code is just this: http://paste.ubuntu.com/8921321/
[15:38] <Laney> yep
[15:38] <xnox> Laney: which is stand-alone, just run that on your desktop with new vte and you know that vte in ubiquity will work.
[15:59] <LocutusOfBorg1> hi Laney finally thanks to someone retrying itk4 have been successful
[15:59] <LocutusOfBorg1> I'm trying to parse update_output to understand what is missing
[16:00] <cjwatson> LocutusOfBorg1: I'm working on it, it's a complicated set of intertwined transitions
[16:00] <LocutusOfBorg1> thanks!
[16:00] <cjwatson> gdcm, hdf5, vdr, etc.
[16:00] <LocutusOfBorg1> hdf5
[16:00] <LocutusOfBorg1> ok so I'm parsing it correctly :)
[16:00] <LocutusOfBorg1> I wasn't sure about the file syntax, is not so much friendly :)
[16:00] <Laney> AFAICS think gdcm is done in itself, but the entagled transitions need work
[16:00] <cjwatson> No, gdcm isn't
[16:01] <Laney> s/think//
[16:01] <Laney> why
[16:01] <cjwatson> Given that I just made three uploads for that earlier
[16:01] <cjwatson> nifti2dicom, plastimatch, vmtk
[16:01] <LocutusOfBorg1> why nifti2dicom hasn't been picked up in the transition file?
[16:02] <LocutusOfBorg1> I was mostly sure about it, but ben says otherwise
[16:02] <cjwatson> no idea, don't care
[16:02] <cjwatson> probably the build-depends field is wrong
[16:02] <cjwatson> i.e. it picks up the libgdcm2.[24] dep despite not having a direct build-dep on libgdcm2-dev
[16:02] <cjwatson> so shrug, sorting it out anyway, the transition tracker isn't important at this point
[16:03] <cjwatson> something's up with plastimatch if you want to have a look at that - FTBFS on amd64 and i386 so far
[16:03] <LocutusOfBorg1> wilco
[16:03] <Laney> I mostly stayed out of the way once I saw that other people were looking at it, so whatever, go wild
[16:04] <cjwatson> I'm also working my way up to scilab (hence the gluegen2 stuff above)
[16:06] <LocutusOfBorg1> cjwatson, plastimatch is (almost) tracked here on debian #768769
[16:07] <pitti> mitya57: just in case you wonder why your lintian merge doesn't land: it breaks current lintian4python; a simple dep bump of the latter isn't sufficient, I filed a Debian bug
[16:07] <LocutusOfBorg1> on amd64 there are some more tests failing
[16:14] <cjwatson> LocutusOfBorg1: I'd be tempted to demote that to -proposed if we get to the point where it's the last remaining blocker
[16:14] <LocutusOfBorg1> the popcon is rather low... so i agree :)
[16:15] <LocutusOfBorg1> in the meanwhile it will either disappear from jessie/get fixed
[16:56] <seb128> whoever changes the urls on the -changes emails to not include the +serie, thanks!
[16:57] <seb128> changed even
[16:58] <seb128> nice to be able to click and have the diff on the page without having the mangle the url manually in the webbrowser
[16:58] <ogra_> OOOH !
[16:59] <ogra_> i'll pay all the drinks for one evening at the bar at the next sprint for whomever did that !!!!
[16:59] <ogra_> this is AWESOME !!
[16:59] <seb128> :-)
[16:59] <seb128> count me in for buying $drinks for whoever did that
[16:59] <ogra_> :)
[17:00] <ogra_> you can take the next evening :)
[17:02] <stgraber> that'd be wgrant: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/17235
[17:02] <ogra_> oh, he will get sooo drunk next sprint :)
[17:02] <stgraber> well, next sprint for him is next week :)
[17:02] <ogra_> well, the next one we all meet :)
[17:13] <slangasek> cyphermox: hi, do you understand the autopkgtest failures at https://jenkins.qa.ubuntu.com/job/vivid-adt-network-manager/lastBuild for network-manager?  I don't see anything failing except a message about qemu processes being killed; not sure if that's an issue with the NM test suite or with the infrastructure
[17:14] <cyphermox> yes, I know what it is
[17:15] <cyphermox> new isc-dhcp has an extra message on stderr
[17:15] <cyphermox> slangasek: the test is trapping this stderr line: wpa-dhclient         FAIL stderr: Killed old client process
[17:16] <cyphermox> I'll fix it shortly, but I was hoping to fix it as I was uploading the new NM
[17:28] <Mirv> pitti: if you can, please find out what's wrong with calibre powerpc. this time it doesn't seem to be just "succeeds on certain machines". (I'll need a rebuild of it done for Qt 5.3.2 landing)
[17:28] <Mirv> so it fails similarly in vivid archives and in my PPA now
[17:48] <slangasek> cyphermox: ok, so it's safe to skip that failure for any migrations it's blocking?
[17:59] <cyphermox> slangasek: yes
[18:06] <doko> cjwatson, ok, there was still an ftbfs issue open, now closed
[18:38] <bdmurray> slangasek: would our missing ddebs for qtcontact5-galera (on amd64, i386, armhf)  have anything to do with address-book-service being copied from a PPA?
[18:38] <slangasek> bdmurray: could, but should not
[18:39] <slangasek> bdmurray: you could ask pitti if there are any remaining known problems with the ddebs handling for ppa copies
[18:45] <bdmurray> slangasek: its odd that if you look here https://launchpad.net/ubuntu/+source/address-book-service/0.1.1+14.10.20140930-0ubuntu1 the utopic builds are for arm64, powerpc, and ppc64el which is what we have ddebs for.
[18:47] <slangasek> bdmurray: ah... so this package was built in an *ubuntu-rtm* ppa, and then binary-copied to utopic
[18:47] <slangasek> bdmurray: that could certainly be a factor
[18:47] <infinity> binary copied to a utopic silo, even.
[18:47] <infinity> Strange workflow.
[18:48] <infinity> So, both sets of builds were in a PPA, but different PPAs.
[18:48]  * slangasek nods
[18:48] <slangasek> so it's probably a case where the ddeb-retriever doesn't know where to retrieve from
[18:48] <infinity> Or, rather, how to reconcile the refs.
[18:48] <infinity> Since the ddebs themselves all come from the same big tarball regardless.
[18:49] <infinity> Of all the temporary hacks I've been party to over the years, this is the one I feel the worst about. :P
[18:55] <tedg> bdmurray, So seb128 convinced me we should move bugs from being on the project to being on the Ubuntu package. I was trying to write a script that would move them. But I can't seem to figure out which tasks are package and which are project. Do you have a script I can steal from?
[18:56] <bdmurray> tedg: I don't know but off the top of my head if "(Ubuntu)" in task then its a package one.
[18:57] <tedg> bdmurray, Do you know what property "(Ubuntu)" would be in? Just parse the title?
[18:58] <bdmurray> tedg: bug_target_name
[19:00]  * tedg tries
[19:10] <bdmurray> tedg: and?
[19:12] <tedg> bdmurray, Nope, looking at other props. Those are all "ubuntu-app-launch"
[19:13] <bdmurray> tedg: Can I see your script?
[19:13] <tedg> bdmurray, http://paste.ubuntu.com/8924781/
[19:14] <bdmurray> tedg: and what project are you using?
[19:15] <tedg> bdmurray, ubuntu-app-launch
[19:16] <bdmurray> tedg: in the for btask loop you are using task
[19:16] <bdmurray> tedg: lines 38 through 41
[19:17] <tedg> bdmurray, Oh, man. Thanks!
[19:17] <bdmurray> no problem
[20:38] <ScottK> infinity: Since you TIL, any objections to adding no-human-maintainers to the tests ignored in the Ubuntu profile.  Seems highly irrelevant for Ubuntu.
[20:41] <infinity> ScottK: You failed to mention a package name there...
[20:42] <infinity> ScottK: lintian?
[20:42] <ScottK> infinity: yes.  sorry
[20:42] <infinity> ScottK: Yeah, that sounds like a reasonable change.
[20:42] <ScottK> Thanks.
[20:43] <infinity> ScottK: Were you asking me to make it, or to +1 you making it? :)
[20:43] <infinity> ScottK: If you do the change, can you forward to Debian, that stuff is all in sync.
[20:43] <infinity> (Our only delta is a nodejs build-dep avoidance thing that I'm trying to convince Debian is sort of okayish)
[20:43] <ScottK> I was asking for you to +1 me making it and I'd forward to Debian, but if for some reason you want to, don't let me stop you.
[20:44] <infinity> ScottK: No, no.  By all means, go nuts.  Do away!
[20:53] <ScottK> Of, of course it needs merging too.
[20:57] <infinity> ScottK: It was *just* merged...
[20:57] <ScottK> OK.  Or I got the old version.
[20:57] <infinity> https://launchpad.net/ubuntu/+source/lintian/2.5.30ubuntu1
[20:58] <infinity> Seems to have made lintian4python unhappy.
[20:58] <ScottK> lintian4python is dead.
[20:58] <infinity> It was also never in unstable even.
[20:59] <infinity> I wonder who synced that from experimental, and why.
[20:59] <ScottK> Dunno.  It was handy when it was maintained, so I guess that's why, but now that it's orphaned, no point in it.
[21:00] <infinity> Right, let's just remove it, then.
[21:00] <ScottK> Please.
[21:00] <infinity> If it ever makes it into sid, it'll come back on its own.
[21:00] <ScottK> Yep.
[21:01] <infinity> ScottK: Done.
[21:01] <ScottK> Excellent.
[21:05] <ScottK> Turns out it's easy to get confused about the current version of something when you just set up a new LTS system and forgot to point the deb-src lines at the devel release.


[00:21] <chrisguk> anyone here
[03:14] <axisys_> so anyone wrote a charm for request tracker?
[03:15] <axisys_> http://bestpractical.com/rt/ for this


[15:22] <tsimonq2> I wonder if this channel is still alive :)
[15:22] <tsimonq2> https://community.ubuntu.com/t/bold-bug-triaging/4334
[15:22] <tsimonq2> That thread is worth some attention.
[15:32] <tsimonq2> rbasak, bdmurray ^^^^
[15:43] <bdmurray> I think what really should happen is somebody should email dino99 and engage in a conversation with them about why they think this is the correct approach. (Perhaps our docs need fixing.) Of course they should also ask them to be more cautious and modify their behavior.
[15:57] <rbasak> bdmurray: who should make contact? Also this person doesn't seem to have a public email address listed on Launchpad.
[15:58] <bdmurray> rbasak: there is a contact this user link on their page though right?
[15:58] <bdmurray> I don't really have time at the moment to engage in a conversation, I think anybody could do it though.
[15:59] <rbasak> bdmurray: ah, I didn't see that. Thanks.
[16:02]  * tsimonq2 doesn't have the time at the moment to do that either (that's why I raised it here)
[18:16] <tsimonq2> This caught my eye... heh
[18:16] <tsimonq2> bug 1752142
[18:16] <ubot5`> bug 1752142 in systemd (Ubuntu) "systemd-networkd supports neither MAC address DHCP nor SendHostname - DO NOT RELEASE BIONIC WITHOUT CHANGING BACK TO dhclient PLEASE PLEASE PLEASE (or else configure netplan to use these options properly)" [Undecided,New] https://launchpad.net/bugs/1752142
[18:21] <rbasak> That should presumably go against netplan?
[18:24] <rbasak> (edited)
[18:38] <cyphermox> rbasak: SendHostname is default, the issue is non-compliant DHCP servers, for which we have bug 1738998
[18:38] <ubot5`> bug 1738998 in netplan "netplan does not allow dhcp client identifier type to be specified" [Wishlist,Triaged] https://launchpad.net/bugs/1738998
[19:13] <rbasak> cyphermox: thanks.


[00:00] <coderanger> Anyone around that knows the first magic to put in the Sources file to make it functionally empty? Trying to make a repo that has deb-src be a noop.
[00:06] <infinity> coderanger: Just make it empty?
[00:07] <infinity> coderanger: Of course, if you're distributing binaries built from copyleft (like, GPL) source, you really don't want your Sources to be empty. :P
[00:07] <coderanger> infinity: "Encountered a section with no Package: header"
[00:08] <coderanger> infinity: These aren't packages built from normal debian-style sources, so deb-src is meaningless
[00:08] <coderanger> but easier to make it a noop than to explain to users why apt-add-repo is wrong :-0
[00:09] <infinity> coderanger: So just don't have a Sources.gz at all if you don't intend to serve deb-src...
[00:09] <infinity> coderanger: apt-add-repository only turns on matching deb-src if people call it with -s/--enable-source
[00:09] <coderanger> No
[00:09] <coderanger> Its the default
[00:10] <coderanger> (unless apt-add-repo was changed since 12.04)
[00:12] <infinity> Anyhow, I don't get the error you do with a zero-length Sources file.
[00:12] <infinity> (Just tested)
[00:12] <coderanger> Hmm, what about with a single newline in it
[00:12] <coderanger> S3 was grumping about 0-byte files
[00:12] <infinity> That would confuse apt, yes.  The first line of Packages/Sources shouldn't be a newline.
[00:12] <coderanger> Okay, hmm
[00:13] <infinity> If you're doing this in a storage scenario that hates zero-byte files:
[00:13] <infinity> (base)adconrad@cthulhu:~/source-test$ : > Sources && gzip -c Sources > Sources.gz
[00:13] <infinity> (base)adconrad@cthulhu:~/source-test$ ls -l
[00:13] <infinity> total 4
[00:13] <infinity> -rw-rw-r-- 1 adconrad adconrad  0 Jan  5 17:13 Sources
[00:13] <infinity> And then upload Sources.gz, but not Sources.  Problem solved.
[00:14] <infinity> -rw-rw-r-- 1 adconrad adconrad 28 Jan  5 17:13 Sources.gz
[00:14] <coderanger> Hah, fair enough
[00:14] <infinity> Most real Debian/Ubuntu mirrors never publish the non-compressed versions anyway.
[00:14] <coderanger> Yeah, I just have the tool generate them for the hell of it
[00:17]  * mwhudson has to laugh at this
[00:17] <coderanger> Hmm, the zero-byte error might be libcloud instead of S3, sigh
[00:21] <coderanger> mwhudson: Hmm?
[00:22] <mwhudson> coderanger: the battle between different unhelpful technologies and the solution of compressing a 0-byte file into a larger thing
[00:24] <coderanger> mwhudson: lolcomputers
[00:24] <mwhudson> yeah
[00:26] <infinity> Well, given the HTTP overhead in requesting and returning a 0-length file, making it 28 bytes isn't really making the problem much worse. :P
[00:29] <RAOF> Hm. Why isn't upstart-dbus-bridge started on the system init?
[00:39] <mwhudson> RAOF: hey, can i bug you about my x problem quickly?
[00:39] <RAOF> mwhudson: Sure
[00:39] <mwhudson> RAOF: every so often i get a short freeze, something restarts
[00:39] <mwhudson> and then some font render buffer is corrupted and i get this sort of thing:
[00:40] <mwhudson> RAOF: http://people.canonical.com/~mwh/mangled.png
[00:40] <mwhudson> (x220 so sandybridge graphics)
[00:40] <mwhudson> RAOF: is this a known problem?
[00:41] <infinity> I get that sometimes with my i915 lockups.
[00:41] <infinity> And sometimes not.
[00:41] <RAOF> Whee! I love font cache corruption.
[00:41] <infinity> (The corruption, that is)
[00:41] <mwhudson> yeah, it's not every time
[00:41] <mwhudson> the lockups themselves seem to happen a lot more when spotify is running, but that might just be anecdata
[00:41] <RAOF> I'm not aware of that problem, but I'm less involved in the X bug triage than I once was :)
[00:42] <infinity> mwhudson: Say, since you're another poor Sandy user, maybe you've seen the weird bug that no one else has ever seen...
[00:42] <mwhudson> RAOF: heh, fair enough
[00:42] <mwhudson> is there some way to dump the cache at least?
[00:42] <infinity> mwhudson: When you open new windows (a new Firefox, a new gnome-terminal, whatever), do they sometimes seem to lose the ability to repaint themselves except when being moved?
[00:42] <mwhudson> infinity: not seen that one
[00:43] <infinity> Weirdst bug ever, cause I seem to be the only one who sees it. :/
[00:44] <mwhudson> infinity: you got lucky with hardware?
[00:44] <infinity> I guess, but it's hardly obscure hardware.
[00:44] <infinity> T420s
[00:45] <infinity> Basically identical to your X220 under the hood.
[00:45] <mwhudson> i mean, you have slightly broken hardware
[00:45] <mwhudson> ?
[00:45] <mwhudson> it's not like i'm the only person in the company with an x220 either :)
[00:45] <infinity> Also possible, but I'd expect broken hardware to behave in more obviously broken ways, not in ways that look like software bugs. :P
[00:46] <infinity> Whereas the Sandy lockups and font cache corruption are things everyone experiences, AFAIK, to varying degrees.
[00:46] <infinity> But my weird "new windows don't know how to window correctly" thing seems unique.
[00:46] <infinity> Or other people just have never sorted out how to describe it and close their non-responsive (not actually, but not painting sure LOOKS unresponsive) windows out of frustration...
[04:17] <alkisg> dpkg: error processing /var/cache/apt/archives/gstreamer1.0-plugins-ugly_1.2.2-1ubuntu2_i386.deb (--unpack):
[04:17] <alkisg>  trying to overwrite '/usr/share/locale/id/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-ugly:i386 0.10.19-2ubuntu2
[04:17] <RAOF> alkisg: Yeah, join the club :)
[04:18]  * alkisg removed gstreamer 0.10 ugly to work around that...
[04:18] <RAOF> You're looking at bug #1266141
[04:18] <alkisg> Thanks, as long as it's reported... :)
[04:18]  * RAOF just --force-overwrite'd it
[04:53] <Logan_> slangasek: Hey, are you around?
[04:56] <Noskcaj> Logan_, Any chance you could look at some stuff on the sponsoring queue? I've got 20+ packages, some of which we really need for xubuntu.
[04:56] <Noskcaj> Also some lubuntu and ubuntu-gnome stuff
[04:57] <Logan_> Noskcaj: Shit, that's a huge backlog. I'm dealing with Bug 1266141 right now (look at how many people affected, ugh), but I'll take a look ASAP.
[04:57] <Noskcaj> thanks. I'm one of the people affected by that bug, so a fix would be great
[04:58] <Logan_> Oh wonderful. More pressure. :P
[04:58] <Logan_> I managed to delete my entire home directory, so working on that first.
[05:02] <Noskcaj> Logan_, nice work ;)
[05:02] <Logan_> Oh, believe me, I'm killing it today.
[05:02] <Logan_> rm -rf gst* != rm -rf gst *
[05:02] <Logan_> Obviously.
[05:02] <Logan_> I don't know why I did that.
[05:04] <Logan_> I think I might have to back out all of the changes to the gstreamer packages if the fix I'm thinking of doesn't work.
[05:05] <Logan_> debdiff. The moment of truth.
[05:05] <Logan_> Oh thank god. It worked.
[05:06]  * Logan_ hugs Noskcaj.
[05:06]  * Noskcaj hugs Logan_
[05:06] <Logan_> Happiness everywhere. Alright. Lemme upload.
[05:06] <Noskcaj> Hopefully my PC will update again now
[05:09] <Fudge> it effects me too but just force installed it as suggested
[05:12] <Fudge> Logan_:  the pressure you must feel :D
[05:12] <Logan_> Tell me about it.
[05:13] <Fudge> she'll be good mate, look at all those 'effected people' cheering you on...
[05:15] <Logan_> Uploaded. Phew.
[05:15] <Logan_> Noskcaj: Now, onto the sponsorship queue.
[05:17] <Noskcaj> Logan_, Could https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-session/light-locker/+merge/196436 be one of the ones you look at? It's a two month old merge and we still need it in xubuntu
[05:17]  * Logan_ looks.
[05:18] <Logan_> Noskcaj: https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1254366/comments/5
[05:19] <Noskcaj> We're wanting to fix this a a basic, no regression way now. Then get it all working fully in upstream for the next release
[05:21] <Logan_> Noskcaj: The patch looks alright. So Jarno is just concerned that it's running a lock command for every possible one, without considering whether or not they are running?
[05:22] <Logan_> Does this cause any error?
[05:22] <Logan_> I guess not, since it's going to /dev/null...
[05:22] <Noskcaj> Logan_, no errors, we've been calling two commands for ages
[05:22] <Logan_> Have you tested it with and without light-locker?
[05:22] <Noskcaj> I haven't personally, but some of the other xubuntu guys have
[05:22] <Logan_> And it's all good?
[05:24] <Logan_> Noskcaj: ^, and you didn't credit Sean.
[05:25] <Logan_> And can I have an upstream bug where this patch was forwarded?
[05:25] <Logan_> Sorry I'm being such a stickler. It's just the process. :)
[05:27] <Noskcaj> I'll try and find one. I think sean might have fixed it upstream already
[05:31] <Logan_> Okay. Try to find a commit.
[05:31] <Logan_> I'll look into the gnome-tweak-tool merge now.
[05:38] <Logan_> Noskcaj: Shouldn't we wait for Debian?
[05:39] <Logan_> At least report it, and maybe forward the patch. We can merge if we approach feature freeze with no response.
[05:39] <Logan_> Another sponsor may disagree, but that's my opinion on new upstream versions.
[05:40] <Noskcaj> Logan_, Request of darkxst, the gnome dev lead. It's been in their testing PPA for ages. Plus pkg-gnome is understaffed, i've got stuff there needing sponsorship for 6 months
[05:40] <Logan_> Fine. Then at least report a bug in Debian requesting a new upstream release.
[05:40] <Logan_> I'll test the merge.
[05:43] <Logan_> I got two conflicts. Please fix.
[05:43] <Noskcaj> Will do. This is why PPA merging is a pain
[05:51] <Noskcaj> I'll redo the merge, since i probably broke something
[06:14] <Noskcaj> Logan_, For some reason that merge error comes up even with just bzr merge-upstream and a dropped patch
[06:14] <Logan_> Noskcaj: That's odd.
[06:14] <Noskcaj> yeah
[06:23] <Noskcaj> I might leave this one till debian update it
[07:04] <xnox> RAOF: hm, dbus-bridge has been changed to run on session-init only these days I think?! Do you have /etc/init/upstart-dbus-bridge.conf that is RC ?
[07:05] <RAOF> xnox: I did not have an /etc/init/upstart-dbus-bridge.conf until I modified the one from it out of /usr/share/upstart/sessions
[07:07] <RAOF> I was just playing with watching NetworkManager events and autogenerating apt-cacher-ng's mirror substitution file from mirrors.ubuntu.com when I change networks, and realised the reason that my job wasn't triggering is that the system init isn't watching dbus :)
[07:10] <xnox> RAOF: i see, so you are the rare case where you _do_ want it on the system-init =)
[07:10] <RAOF> I just wondered if there was some reason why the system-init no longer watched dbus :)
[07:18] <xnox> RAOF: well, in session-init (were most dbus events are used at the moment) it was that "session dbus" events were naked, yet "system dbus" events would arrive with "sys:" prefix. So we moved system-init system-dbus-bridge to session-init only.
[07:19] <xnox> if we ever get dbus-bridge using jobs in default / system-init, then we can look into having sys:dbus events filtered out on the session-init size.
[07:19] <xnox> (side)
[09:00] <Noskcaj> Logan_, On the xfce-session stuff, there's no upstream bug, but the upstream devs also work on light locker, so it will be done soon. please approve the branch
[09:01] <Logan_> Noskcaj: Please file a bug. :)
[09:01] <Noskcaj> I'll do that tomorrow, need sleep now.
[09:50] <tester56> what does apport-noui do exactly? (it is stated that it automatically submit bugreports, but does it do so when "sumbit bug reports to canonical" is disabled?)
[10:19] <doko> jamespage, why is this golang patch not applied in debian?
[10:19] <jamespage> doko, differences in the way dpkg detects shared library deps (I think)
[10:20] <jamespage> doko, I can probable persuade the debian maintainer to take that patch
[10:20] <jamespage> I think it should not effect the debian builds negatively
[10:28] <doko> wgrant, your pykde4 upload now lets python3-pyqt4 depend on both libpython3.3 and libpython3.4. it should not directly link the extension against the shared library
[11:06] <doko> I do love embedded waflib copies everywhere ...
[11:06] <ogra_> can't have enough of them :)
[11:12] <jtaylor> can someone reproduce the skimage adt failure?
[11:12] <jtaylor> I can't in a chroot or adt-run
[11:15] <jtaylor> (ignore the 3.4 failure, adt chokes on py3.3 which I can'T reproduce)
[12:32] <doko> jtaylor, https://launchpadlibrarian.net/161710633/buildlog_ubuntu-trusty-arm64.fftw3_3.3.3-7ubuntu1_FAILEDTOBUILD.txt.gz
[12:32] <doko> did you introduce this?
[12:32] <doko>   * enable runtime detected neon support for arm64
[12:32] <jtaylor> yes
[12:32] <jtaylor> I was told (here) arm64 has neon
[12:35] <jtaylor> so why doesnt it work? no hardware or gcc does not support it?
[12:36] <xnox> jtaylor: neon is uncoditional on arm64 and it's supperset of armhf, so one doesn't need to specify neon build flags
[12:37] <jtaylor> interesting, gcc could ignore the flag then ...
[12:37] <jtaylor> fix requires a change the the build system
[12:37] <xnox> jtaylor: it's wrong to set it. cause you might be forcing an armv7 build instead of armv8.
[12:37] <jtaylor> dropping --enable-neon will disable neon altogether even if its auto-on
[12:38] <xnox> jtaylor: remember that arm64 can execute armv7/32bit binaries with neon.
[12:38] <jtaylor> patches accepted, I don't have the hardware to test it
[12:38] <xnox> jtaylor: mk-sbuild --arch arm64?
[12:38] <xnox> jtaylor: mk-sbuild --arch arm64 trusty?
[12:39] <jtaylor> that works now?
[12:39] <jtaylor> nice
[12:39] <xnox> jtaylor: it worked since trusty opening, saucy release had small bug in qemu-debootstrap however.
[12:40] <jtaylor> but I don't use sbuild
[12:41] <xnox> jtaylor: use whatever you use, there is qemu-user-static binary for arm64.
[12:41] <xnox> so you can execute native arm64 chroots.
[12:41] <jtaylor> meh I don't have time for that now, patch it out, I'll fix it when it gets a problem in debian
[12:41] <jtaylor> fftw needs merging anyway
[12:42] <xnox> jtaylor: yeah back it out in ubuntu or debian or both.
[12:42] <xnox> cause otherwise fftw will be stuck in -proposed.
[12:42] <jtaylor> its main so nothing I can do
[12:43] <jtaylor> or better its more time efficient for someone else to drop the two lines
[12:43] <xnox> jtaylor: i think you should do it =)))) you could have pastebined patch "enabling neon arm64" asking anybody here to test it.
[12:43] <jtaylor> I did
[12:44] <jtaylor> was told it works, so I did it to save an extra upload
[12:44] <xnox> jtaylor: and there was a non-ftbfs build log?
[12:44] <jtaylor> at the time it was said qemu arm64 does not work yet
[12:44] <xnox> jtaylor: yes, neon works on arm64. that build FTBFS however.
[12:44] <jtaylor> asier to just do it on real hardware and see then
[12:45] <jtaylor> which is what I did
[12:45] <jtaylor> now we have the result :)
[12:45] <jtaylor> and can fix it
[12:48] <jtaylor> I'm happy to take any patches and forward them upstream
[12:48] <jtaylor> if you don't want to bother creating one drop the two lines in debian/rules and disable it altogether
[12:48] <jtaylor> I may have time to look into it myself but not today
[12:49] <jtaylor> sorry for abusing ubuntu as my testing platform, should have asked for a buildlog when I did this
[12:53] <jtaylor> information needed for a proper patch is how to detect arm64 in configure.ac
[12:55] <jtaylor> hm a debian specific one is simpler as we can assume gcc supports fpu=neon
[12:55] <cjwatson> jtaylor: aarch64*
[12:55] <jtaylor> just dropt he gcc check
[12:55] <cjwatson> (in case "${host_cpu}" etc.)
[12:55] <jtaylor> do you know an example of the top of your head?
[12:56] <cjwatson> I was basing that on the "dnl configure options" block near the top of configure.ac
[12:56] <cjwatson> the arm64 triplet starts with "aarch64" so you can use that
[12:57] <cjwatson> cf. "dpkg-architecture -aarm64 -qDEB_HOST_GNU_TYPE" (ignore stderr)
[12:57] <mitya57> jtaylor: If you prefer pbuilder over sbuild, then 'pbuilder-dist trusty arm64 create' should do the thing
[12:57] <jtaylor> mitya57: not in saucy :/
[12:57] <jtaylor> not running trusty yet
[12:57] <jtaylor> oh no
[12:57] <jtaylor> I'm just dumb and mixed upt he ordering
[12:58] <jtaylor> k then I can give it a try today
[12:58] <mitya57> You can always backport ubuntu-dev-tools & qemu-debootstrap
[13:01] <jtaylor> qemu backport requires more backports :/
[13:01] <xnox> jtaylor: yeah, for host_cpu aarch64 it should define have_neon & not mangle gcc flags. But do get that test-built before uploaded.
[13:01] <xnox> jtaylor: qemu-user-static are statically linked binaries... so just download the deb & unpack arm64 static binary out of it.
[13:01] <xnox> (or install trusty qemu-user-static)
[13:02] <jtaylor> nice thx
[13:02] <xnox> jtaylor: or run nested chroots.... =) chroot into trusty, then create arm64 pbuilder/sbuild/whatever chroot there for arm64.
[13:03] <jtaylor> why must arm64 look like amd64 :( I always click the wrong linkg when downloading debs
[13:05] <jtaylor>  /usr/sbin/qemu-debootstrap --arch arm64; E: Sorry, I don't know how to support arch
[13:06] <jtaylor> version 1.7.0
[13:06]  * xnox votes to rename all arches using UUIDs
[13:06] <xnox> jtaylor: yeah that's the other bit i've fixed in trusty. it's a shell script with hard-coded names of arches it knows about....
[13:06] <xnox> (or maybe it wasn't shell, it's just a script...)
[13:08] <jtaylor> I installed the trusty versiion
[13:08] <jtaylor> 1.7.0+dfsg-2ubuntu5
[13:09] <jtaylor> xnox: ^
[13:10]  * xnox wonders if it got broke again.
[13:13] <xnox> hallyn: looks like 1.7.0+dfsg-2ubuntu1 merge reverted/dropped changes I've applied in 1.6.0+dfsg-2ubuntu4
[13:14] <xnox> hallyn: where/how should they be done, to not get lost? as qemu-debootstrap for arm64 is now broken again...
[13:15] <xnox> debian/binfmts/qemu-arm64 possibly also reverted, not sure.
[13:24] <didrocks> stgraber (or other lxc gurus): do you know if you can mount /proc in a lxc container? My debootstrap is failing me on that one: W: Failure trying to run: chroot /var/cache/pbuilder/trusty-amd64/base.cow/. mount -t proc proc /proc
[13:25] <asac> didrocks: not sure if its relevant, but i see something about lxc config to mount proc/sys here: http://l3net.wordpress.com/2013/11/03/debian-virtualization-lxc-debootstrap-filesystem/
[13:25] <asac> lxc.mount.entry=proc /proc proc nodev,noexec,nosuid 0 0
[13:25] <asac> lxc.mount.entry=tmpfs /dev/shm tmpfs  defaults 0 0
[13:25] <didrocks> asac: I guess this is to mount /proc into the container, let me look/have a try
[13:29] <didrocks> asac: yep, that didn't do it from what I tried
[13:29] <jtaylor> xnox: ping me when its fixed and I'll have a look (bin/qemu-arm64-static also does not exist)
[13:29] <jtaylor> that its in proposed doesn't matter, the only really relevant change is arm64 support
[13:31] <asac> ogra_: xnox: do you know about lxc (see didrocks question above)? if not, anyone besides stgraber who might know?
[13:32] <jtaylor> actually is arm64 build now required for proposed migration?
[13:32] <ogra_> there shouldnt be anything blocking you from mounting /proc
[13:33] <didrocks> ogra_: weird, I used the ubuntu template to create my container though
[13:33] <xnox> didrocks: i think by default you cannot mount / remount proc from inside the lxc container. You should either specify it in the template on the host side, or grant the container to do so (note it's a security risk and apparmor will block from doing so as well)
[13:33] <xnox> didrocks: what's your use-case / what are you trying to achieve?
[13:34] <ogra_> xnox, better ask what is pbuilders use-case :)
[13:34] <didrocks> xnox: I'm just trying to test locally my new ci system (pbuilder/cowbuilder are used to create source package) and I didn't want to install jenkins on my desktop, so lxc container ;)
[13:34] <xnox> jtaylor: the requirement is imposed by britney and it's same as it always been, the built architectures should not regress - since there if fftw3/3.3.3-5ubuntu1 built on arm64, it should continue to be built on arm64.
[13:35] <xnox> jtaylor: and enforced by release & archive teams =)
[13:35] <didrocks> (and the jenkins CI job is using then the pbuilder/cowbuilder, that's why I'm trying to create one inside the container)
[13:35] <xnox> didrocks: right, i think we do apparmor confinment on the lxc containers by default, but there was a  key / config to disable apparmor confinment for a given lxc container.
[13:36]  * asac lunch
[13:36] <xnox> didrocks: (reboot of the host may be required)
[13:36] <xnox> didrocks: alternatively $ juju bootstrap lcy01 / lcy02 and have disposable things to install jenkins on ;-)
[13:36] <didrocks> xnox: interesting, ok, let me have a look :)
[13:36] <cjwatson> xnox: not so much enforced as we generally decline to overrule the automation :)
[13:37] <cjwatson> jtaylor: full docs: https://wiki.ubuntu.com/ProposedMigration
[13:37] <didrocks> xnox: right, the thing will be jujuifed, but right now, local development :)
[13:37] <jtaylor> thx
[13:38] <xnox> didrocks: i at times launch throwaway instances in couple of click through dashboard.cs.c.c  to install things like jenkins to not trash my host, nor sufficate from my small VM sizes / lxc container restrictions.
[13:39] <caribou> xnox: I gave a shot to merging backuppc following Logan's confirmation that he would not work on it
[13:45] <tester56> will qt 4.8.5 land in trusty?
[13:47] <mitya57> tester56: yes, it's almost ready
[13:47] <mitya57> Waiting for Rohan to do some final testing & upload
[13:48] <ogra_> pfft ... 4.8 ... use 5.x !
[13:48] <ogra_> :)
[13:48] <mitya57> ++ogra_
[13:48] <tester56> would resolve a few crashes: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1200523
[13:49] <tester56> see also https://bugs.kde.org/show_bug.cgi?id=302931
[13:49] <tester56> just experienced one crash yesterday with trusty
[13:50] <mitya57> the first bug is marked as already fixed
[13:51] <caribou> xnox: I Have a bzr branch ready if you want to have a look
[13:51] <mitya57> the second one looks like the same issue
[13:55] <xnox> caribou: make a merge proposal against lp:ubuntu/$package
[13:55] <xnox> caribou: leave the default reviewers.
[13:55] <xnox> caribou: and request a second review from me (~xnox)
[13:55] <xnox> (that way i get notified, and it will also land in the sponsorship queue report)
[13:55] <caribou> xnox: I used lp:ubuntu/backuppc/trusty-proposed as a reference branch, is that correct ?
[13:55] <tester56> mitya57: yeah is the same issue, but according to the bug report it is only resolved using 4.8.5 ...
[13:57] <xnox> caribou: lp:ubuntu/backuppc
[13:57] <caribou> xnox: the source branch ?
[13:58] <xnox> caribou: if trusty-proposed was ahead of ubuntu/backupppc, you'd add your changes on top of lp:ubuntu/trusty-proposed/backuppc but still make merge proposal into lp:ubuntu/backuppc
[13:58] <caribou> xnox: ok, I'll check both & rebuild if needed
[13:58] <xnox> caribou: it doesn't matter in this case as both lp:ubuntu/backupppc and lp:ubuntu/trusty-proposed/backuppc are the same, 3.2.1-4ubuntu2 is last version in either of the branches.
[13:59] <caribou> xnox: k
[14:06] <knocte> is medibuntu down? I can't access http://packages.medibuntu.org/
[14:06] <ogra_> knocte, support is in #ubuntu
[14:07] <knocte> sorry
[14:07] <ogra_> (and i think medibuntu stopped a while ago)
[14:10] <stgraber> didrocks: you can but not with the default apparmor profile as doing so is a security risk.
[14:12] <didrocks> stgraber: ok, that confirms then, I'll fetch your documentation as well on what needs to be disabled then
[14:13] <xnox> stgraber: as alternative, i've directed didrocks to use beefy canonistack instances, instead of local lxc containers.
[14:15] <stgraber> didrocks: let me grab you my sbuild LXC apparmor profile, that should do the trick for you.
[14:16] <didrocks> stgraber: ah, excellent, that should unblock me for the short term (like today) and I'll then look at canonistack within the week
[14:17] <stgraber> didrocks: set lxc.aa_profile to lxc-container-default-builder for your container
[14:17] <stgraber> didrocks: then create /etc/apparmor.d/lxc/lxc-default-builder containing: http://paste.ubuntu.com/6703385/
[14:17] <stgraber> didrocks: after that, do "sudo /etc/init.d/apparmor reload" and restart your container
[14:19] <stgraber> didrocks: those rules are enough for me to run sbuild here (used for LXC's own CI environment), I'm only guessing they should work with pbuilder too. If something still fails, let me know (with a copy of the dmesg output) and I'll tell you what to add.
[14:20] <mitya57> Funny MP: https://code.launchpad.net/~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src/+merge/200535 - states that DFSG is not mandatory in Ubuntu
[14:20] <mitya57> I believe it is, at least in main/universe
[14:21] <mitya57> Thoughts?
[14:21] <cjwatson> mitya57: He's sort of correct; for non-code elements the Ubuntu licensing policy states that we'll consider them case-by-case
[14:22] <cjwatson> Though it's still good practice to do things in a Debian-mergeable way where possible
[14:22] <cjwatson> mitya57: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-ulp
[14:22] <mitya57> Yes, will ask if we can skip tests that need such data
[14:23] <cjwatson> (last para of that section)
[14:23] <didrocks> stgraber: worked perfectly! Thanks a lot :)
[14:25] <stgraber> didrocks: good to hear! np
[14:43] <hallyn> xnox: hm.  well i keep the source at github.com/hallyn/qemu, but I looked at all the debdiffs in the archive so shouldn't have lost any changes.  i'll look at 1.6.0+dfsg-2ubuntu4 again - though my internet is dead so i'm on ip-over-pigeon right now.
[14:44] <mlankhorst> erm
[14:44] <mlankhorst> is it just me or is the toolchain messed up ?
[14:44] <mlankhorst> checking if gcc -std=gnu99 static flag -static works... *** Error in `/usr/bin/ld': corrupted double-linked list: 0x091a6558 ***
[14:44] <mlankhorst> on i386
[15:00] <mlankhorst> gcc -std=gnu99 -o conftest -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -DPRE_RELEASE=0 -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-Bsymbolic -static conftest.c
[15:01] <mlankhorst> $ cat conftest.c
[15:01] <mlankhorst> int main(){return 0;}
[15:08] <mlankhorst> /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail ../../bfd/elflink.c:13053
[15:08] <dholbach> xnox, seb128: do you know what might cause this: http://paste.ubuntu.com/6703638/ ?
[15:08] <mlankhorst> bleh
[15:08] <dholbach> it happens when running http://paste.ubuntu.com/6703644/
[15:08] <mlankhorst> anyone wants to look at that toolchain failure?
[15:09] <seb128> dholbach, I don't
[15:10] <dholbach> seb128, should I file a bug for it?
[15:10] <xnox> dholbach: arch mis-match? what's your "host" / main arch, and which foreign arches are enabled?
[15:10] <xnox> dholbach: you shouldn't need to install "ubuntu-sdk-libs-dev:armhf" that's already installed (abeit partially)
[15:11] <mlankhorst> bleh
[15:11] <mlankhorst> does gcc -fPIE -pie make sense on a static binary?
[15:11] <xnox> mlankhorst: on some arches =)))))))
[15:11] <mlankhorst> xnox: -static -fPIE -pie ?
[15:11] <dholbach> xnox, I just wanted to make sure that everything's installed, to make sure it works as part of instructions for folks to compile their QML extensions
[15:11] <mlankhorst> well I guess it might
[15:11] <xnox> mlankhorst: oh pie, not pic. hm.... not sure.
[15:12] <seb128> dholbach, I guess you can, though I'm not the best person to ping about multiarch issues, let's see if xnox manages to help you ;-)
[15:12] <mlankhorst> still staticaly linked and movable
[15:12] <cjwatson> dholbach: no, you shouldn't put that in instructions.  anything that click chroot create doesn't already install that's needed would be a bug in click
[15:12] <xnox> dholbach: the instructions should be - click create, cmake compile.
[15:12] <cjwatson> please don't work around software bugs in instructions ...
[15:12] <cjwatson> (if it is a bug)
[15:13] <xnox> cjwatson: should i seed cmake:native somewhere, or can you install one, btw?
[15:13] <dholbach> cjwatson, no, I didn't want to work around software bugs - I just assumed that ubuntu-sdk-libs-dev would give people everything they potentially need to compile their QML extensions
[15:13] <xnox> dholbach: where are these instructions you are talking about?
[15:13] <cjwatson> dholbach: click chroot is already meant to install everything they need
[15:13] <dholbach> xnox, there are none right now
[15:13] <dholbach> cjwatson, ok, thanks
[15:13] <cjwatson> xnox: send me an MP with a suitable change to click/chroot.py?
[15:14] <xnox> cjwatson: ack.
[15:15] <dholbach> (and this was just for playing around locally)
[15:16] <dholbach> tedg, who could nudge https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 along? :)
[15:17] <tedg> dholbach, charles_ has been doing most of those reviews, considering the weather, sending hot chocolate is probably your best bet :-)
[15:18] <dholbach> tedg, thanks
[15:19] <dholbach> charles_, if you have a bit of time, it'd be fantastic if you could review the MP mentioned above :)
[15:31] <charles_> dholbach: I'll review it asap, it's third on my list right now
[15:31]  * dholbach hugs charles_
[15:31] <dholbach> thanks a bunch!
[15:31] <charles_> hm, when did I pick up an _ on my nick
[15:32] <xnox> tedg: that would be Ice Frapuchinno on arrival ;-)
[15:33] <tedg> xnox, You clearly don't believe in the magic that is dholbach ;-)
[15:33] <tedg> It is freaky cold though.  Staying inside today.
[15:34] <xnox> tedg: very cold here as well, i've put on socks today with my flip-flops. =))))))
[15:34] <ogra_> tedg, just come over to europe ... we are stuck in eternal fall/spring here
[15:34] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492 causes a FTBFS when attempting to rebuild existing xorg-server too
[15:36] <xnox> tedg: is it just me or click app launcher can block until the app is started? e.g. like with normal upstart job one has $ start foo; and $ start --no-wait foo. First one will block, until foo is started. The second one, will return immediately.
[15:37] <xnox> tedg: i'm asking because starting click apps in the  emulator, on underclock CPUs of cloud instances take forever wall-clock time, and autopilot currently timesout within "10 seconds" (actually 10x1s sleeps, which are subject to poor clock resolution)
[15:37] <tedg> xnox, I think that should work, but the cascading may break it.  I haven't tested.  But that changes a lot in the proposed MRs, so I wouldn't test on trunk today.
[15:37] <dholbach> tedg, I could ask the XKCD guy to find out how hot a hot chocolate would need to be to survive 8200km and still be nice and warm ;-)
[15:38] <xnox> tedg: i'm testing as it is on the current system-images (stock, no ppas enabled etc.)
[15:38] <tedg> dholbach, Wonder if you could get one of those containers they store liquid nitrogen in... they're very insulated.
[15:38] <xnox> dholbach: isn't that same as http://what-if.xkcd.com/1/ ?
[15:39] <tedg> xnox, That's old :-)  You might see if the behavior is different if you call "application-click" directly.
[15:39] <xnox> tedg: right, let me compare with what autopilot code actually calls....
[15:39] <dholbach> xnox, if the hot hot chocolate experiment resulted in http://what-if.xkcd.com/imgs/a/1/05.png I'd probably try tedg's approach first :-)
[15:42] <xnox> tedg: autopilot does "$ start application APP_ID=$(app_id)" that doesn't block does it?
[15:42] <xnox> (can it be optionally made to block?)
[15:45] <tedg> xnox, It calls "start" for the sub-jobs, which should block, no?
[15:45] <tedg> xnox, But, again, that's going to change a lot, so I'd not want to fix it for trunk today.
[15:46] <xnox> tedg: right, i'll work around that in my juju charm then.
[15:46] <xnox> (for now)
[15:46]  * xnox needs proof of concept anyway.
[16:23] <bdmurray> xnox: bug 1022815, which you commented on at one point in time has had a patch added
[17:37] <charles> dholbach, ted: https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 approved
[18:37] <hallyn> jdstrand: regarding test-libvirt.py in qrt;  it does a device-detach then checks whether the device was removed from apparmor profile.  However, libvirt now waits for qemu to say the device is removed before actually removing the device, and since the guest image doesn't do acpi that never happens
[18:37] <hallyn> jdstrand: so do you prefer to (a) add acpi to the guest image, (b) check that the device is in the vm's xml and skip the apparmor check if so, or (c) skip the test on new libvirt?
[19:31] <smagoun> cyphermox: Hi, do you know if anyone is looking at the nm-applet bug that results in multiple "Authetication Required" dialogs onscreen? It's lp:#1224040; the bug is still present in 14.04.
[19:41] <cyphermox> smagoun: it was supposed to have been fixed long ago, I'm going to ask upstream. I certainly haven't seen it happen in a long while here and I used to get that to show up pretty easily
[19:42] <smagoun> cyphermox: It's easy enough for me to reproduce. I came back to a machine that was idle for 2 weeks, if my math is right there were 3196 dialogs onscreen. :/ nm-applet was using 2.4GB of ram
[19:42] <cyphermox> oh, I believe you :)
[19:43] <smagoun> cyphermox: anyway, thanks  for checking with upstream. Let me know if there is anything I can do to help debug/test!
[19:43] <cyphermox> sure
[19:44] <cyphermox> I discussed this with dcbw a few times already, I'll just remind him and let him know it's still broken
[19:46] <sarnold> oooof, 3196 dialogs? did you grab a screenshot?
[19:47] <roadmr> sarnold: I think all the dialogs are superimposed, so they look like a single dialog (but with an evil thick black border)
[19:48] <sarnold> roadmr: heh, those must be some very menacing pixels indeed :)
[19:49] <roadmr> sarnold: haha :) yes, it's just the merged drop shadows from all the dialog but it looks weird somehow
[19:50] <smagoun> sarnold: no screenshot no, but I have a witness (pmcgowan, who is not in this room right now) . You can see all the dialogs using super-w in unity, which is sloooooooooooow with that many dialogs
[19:52] <sarnold> smagoun: oh well, it sounds less impressive than I hoped for. :)
[19:53] <smagoun> :)
[21:20] <nashant> Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to says it's gone. I'm fed up with the rubbish power indicator with no brightness control
[21:26] <Noskcaj> cjwatson, bug 1266516
[21:35] <jdstrand> hallyn: ok, I'm here (and still trying to climb out of holiday backlog)
[21:36] <jdstrand> hallyn: I think ideally we would adjust the vm to have acpi, since the code is all still there to do this in libvirt and we should be testing for it
[21:38] <jdstrand> hallyn: iirc, the libvrt vm is dapper. if there were other reasons to update the vm that would be helpful for adding tests, then I would go that route. otherwise, skip the test until such time as you want to regenerate the vm?
[21:40] <hallyn> jdstrand: how did you generate the vm?  wonder if i coudl just update sources.list and have it work :)
[21:41] <jdstrand> hallyn: see QRT/scripts/libvirt/README.qatest
[21:41] <hallyn> k
[21:42] <jdstrand> hallyn: basically, that should work. it is just ubuntu-minimal + ssh
[21:42] <cjwatson> Noskcaj: ack, will try to look this week; it generally takes some time
[21:42] <hallyn> built using vmbuilder, which is being dropped :)
[21:44] <nashant> Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to says it's gone. I'm fed up with the rubbish power indicator with no brightness control
[21:46] <cyphermox> smagoun: I think I may have just made sense of it now... going to test a patch
[22:16] <smagoun> cyphermox: NIce! I'd be happy to test too
[22:19] <stgraber> cjwatson: I've got an e-mail in the u-d-a queue when you have a minute
[23:12] <infinity> stgraber: Accepted.


[17:06] <czajkowski> popey: do you think people use ubuntu desktop edition as a production server
[17:13] <popey> people who are just learning might
[17:13] <popey> normal proper well qualified people almost certainly don't
[17:18] <czajkowski> thats what I'm trying to get someone to understand
[20:31] <knome> unfortunately, not all server-related businesses are ran by "normal proper well qualified people"


[06:15] <mborzecki> morning
[06:23] <mup> PR snapd#11788 closed: secboot/keymgr: extend unit tests, add helper for identify keyslot used error <Simple 😃> <factory reset 🔌> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11788>
[07:10] <pstolowski> morning
[07:33] <mardy> pstolowski, mborzecki, hi!
[07:34] <mardy> mborzecki: that issue with sshfs and getting the current directory, maybe it's not such a corner case. I'm starting to think that this autofs bug hits the same issue https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1784774.
[07:34] <mup> Bug #1784774: snapd is not autofs aware and fails with nfs home dir <snapd:Fix Released by zyga> <firefox (Ubuntu):Confirmed> <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1784774>
[07:35] <mardy> at least the logs provided by Andrew, show that after a snapd restart, NFS is detected and there are no network denials; but still running a snap fails
[07:35] <mardy> (and no apparmor denials are reported)
[08:08] <mborzecki> mardy: about https://bugs.launchpad.net/snapd/+bug/1973321 it's probably itenntional that the current dir fd is set up early, but maybe it's ok to do it as the user, i.e. switching to real uid/gid before?
[08:08] <mup> Bug #1973321: snaps dont't start when current working directory is on sshfs <snapd:New> <https://launchpad.net/bugs/1973321>
[09:26] <mardy> mborzecki: yes. On the other hand, we can move it a bit below, I'm preparing a PR now
[09:49] <mup> PR snapd#11792 opened: many: structured startup timings <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11792>
[10:39] <mardy> wierd, unless I'm doing something terribly stupid, dropping permissions is not enough (see the commit message): https://github.com/mardy/snapd/commit/7e3a58b5e41f3f64aec54106aa2eeff6d1addcd4
[10:45] <mborzecki> mardy: and cwd is on a fuse mounted fs?
[10:47] <diddledani> I think I have caught the tests modifications needed now, so hopefully spread will pass https://github.com/snapcore/snapd/pull/11785
[10:47] <mup> PR #11785: snap-confine: add WSL2 GPU support to strict confinement <Created by diddledani> <https://github.com/snapcore/snapd/pull/11785>
[10:48] <mardy> mborzecki: yes
[11:09] <mup> PR snapd#11768 closed: o/snapshotstate: add ~/Snap to snapshots <Created by MiguelPires> <Closed by MiguelPires> <https://github.com/snapcore/snapd/pull/11768>
[11:31] <mardy> mborzecki: bad news, it seems that the FUSE kernel module checks not only for the effective user ID, but also for the real one: https://github.com/torvalds/linux/blob/master/fs/fuse/dir.c#L1223-L1240
[11:32] <mardy> ("uid" is the real one)
[11:37] <mborzecki> mardy: heh, so looks like there's no way to get it working
[11:57] <diddledani> mborzecki: not from snapd's side, methinks - it requires the right mount option to allow_root
[12:05] <mup> PR snapd#11781 closed: o/snapstate: remove deadcode breaking static checks <Simple 😃> <Created by MiguelPires> <Merged by MiguelPires> <https://github.com/snapcore/snapd/pull/11781>
[12:12] <mborzecki> diddledani: yeah, mardy was trying to find a way without needing to tweak the mount flags, but it looks like that may be no way around it
[12:13] <diddledani> :'(
[12:34] <mardy> mborzecki, diddledani: I added a comment in https://bugs.launchpad.net/snapd/+bug/1973321, I think there is a way, but it would require quite some changes to snap-confine
[12:34] <mup> Bug #1973321: snaps dont't start when current working directory is on sshfs <snapd:New> <https://launchpad.net/bugs/1973321>
[12:53] <mborzecki> mardy: hm not sure about the caps, we would need to talk to security, caps are too easy to get wrong 🙂 and i think you still need CAP_SYS_ADMIN, but then you wouldn't be able to drop that until the end, would you?
[12:54] <mborzecki> or at least not until unshare()
[12:54] <mborzecki> and then CAP_BPF, for a while longer?
[13:50] <mup> PR snapd#11771 closed: tests: spread test for uc20 preseeding covering snap prepare-image <Preseeding 🍞> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11771>
[15:51] <mup> PR snapd#11733 closed: snap/quota: add values for journal quotas (journal quota 2/n) <Simple 😃> <Created by Meulengracht> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11733>
[17:16] <mup> PR snapd#11793 opened: tests: fix auto-refresh-gating test forcing reset-failed before restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11793>


[09:06] <Fudge> is gnome-session responsible for the session-manager logout screen?
[11:05] <directhex> Laney, tomboy in trusty > in debian - can you handle dbus#2 on it?
[11:09] <directhex> baby getting in the eay today
[13:22] <dufa> join #ubuntu-on-air
[13:22] <dufa> uups
[19:04] <juliank> Logan_: I see that you are mass bug filing over in the Debian BTS, (about to) ignore developers reference 7.1.1
[19:04] <Logan_> maintonly?
[19:05] <juliank> Yes, it says you should write to maintonly, at least if you're continuing at that rate, otherwise bug mailing list ends up with many emails from you.
[19:06] <juliank> I don't know how many bugs you are about to report, but if they are more than ten, I'd have expected a mail to debian-devel first.
[19:06] <juliank> If a really large number of packages is affected, it might have made more sense to add a lintian check or something similar first, and wait before reporting the bugs.
[19:07] <Logan_> Hmm, okay. I'm submitting Ubuntu deltas using submittodebian for fixing FTBFSes on ppc64el.
[19:07] <Logan_> I tend to fix a good amount, maybe ten, and then I submit them all to Debian.
[19:08] <Logan_> I don't think submittodebian lets me write to maintonly... :/
[19:10]  * Logan_ pokes bdrung and xnox ^
[19:10] <juliank> Logan_: You could add "maintonly" to your reportbugrc before using it, and remove it when you're done with the batch
[19:11] <Logan_> I'm wondering if there's a way for me to pass options to reportbug with submittodebian.
[19:11] <Logan_> Something like $ submittodebian -- --maintonly
[19:12] <bdrung> you probably have to look at the source code (if the man page does not tell you)
[19:12] <Logan_> Okay, I'll take a look. I'll do what Julian suggested otherwise.
[19:13] <Logan_> juliank: Thanks for the heads up!
[19:13] <Noskcaj> Could someone take a look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/libgweather/3.10.1/+merge/200210 ?
[19:14] <Logan_> Looking.
[19:15] <Logan_> Oh, that's in main.
[19:15] <Logan_> Can't do that. :P
[19:24] <Noskcaj> Logan_, Since you always seem so willing to put up with my requests, xubuntu needs a new terminal version. https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-terminal/0.6.3/+merge/200151
[19:24] <Logan_> Well, I did merge your last xfce4-terminal.
[19:24] <Logan_> So it only seems right.
[19:25] <Noskcaj> ty
[19:27] <Logan_> Noskcaj: dpkg-source: info: local changes detected, the modified files are:
[19:27] <Logan_>  xfce4-terminal-0.6.3/terminal/terminal-encoding-action.c
[19:29] <Noskcaj> Stange. I looks like that somehow got deleted. One second
[19:32] <Logan_> cjwatson: I know I'm not supposed to file bugs for removing Ubuntu packages without deltas that were removed from unstable, but I was going through the list, and there are a number of packages for which I can't figure out why they haven't been removed yet.  I think bzr merge might have deleted it for you
[19:49] <Logan_> No, it wasn't deleted. There were changes to it.
[19:52] <Noskcaj> Also, meld says it's identical. Try just getting my branch and building from it
[19:57] <Logan_> Noskcaj: Okay, I'll try that.
[19:59] <Noskcaj> ty
[21:39] <cjwatson> Logan_: process-removals checks for seededness and reverse dependencies, and I'll often defer removals in those cases.  feel free to prod me and I can look into whether it's some kind of systemic problem or what
[21:40] <Logan_> cjwatson: Okay, so, automake1.7 for example. Removed from unstable back in August 2012, no rdeps or rbdeps, and not seeded.
[21:41] <cjwatson> Logan_: oh, that's probably just that it took ages for all the rbdeps to go away and I only very occasionally retry it for removals that far back
[21:41]  * cjwatson runs "process-removals -d 2012-01-01"
[21:44] <cjwatson> also I tend to think a bit harder about anything with Ubuntu modifications (not that that applies in this case), since that might imply specific interest by somebody in Ubuntu
[21:44] <Logan_> Gotcha.
[21:45] <Logan_> ant1.7 is another one on my list that I've been compiling. Has two rbdeps, but they're both alternates.
[21:45] <cjwatson> Yeah, I just got to that.
[21:45] <cjwatson> About to remove it
[21:55] <cjwatson> Logan_: Anyone can run process-removals from lp:ubuntu-archive-tools to see the logic it uses, even if only AAs can do the actual removal; so if you fancy making it less slow and unreliable, and maybe figuring out how we could track the delta better ...
[21:56] <cjwatson> (ant1.7 and automake1.7 removed now)
[21:56] <Logan_> I will look into that. :)
[21:56] <cjwatson> Possibly better than you writing your own thing :)
[21:56] <cjwatson> process-removals really hasn't had more than, um, emergency love
[22:08] <Logan_> cjwatson: Wait so...
[22:08] <Logan_> process-removals goes through all removals from all time?
[22:08] <cjwatson> Logan_: I generally pass -d
[22:08] <cjwatson> for something vaguely recent
[22:09] <Logan_> Yes, but I feel like there are so much more efficient ways to do this.
[22:09]  * Logan_ ponders.
[22:09] <cjwatson> It's not very satisfactory
[22:09] <cjwatson> I've never had the effort to rewrite it
[22:09] <Logan_> I might make this a project for myself.
[22:09] <cjwatson> It'd certainly be great for somebody to improve this; I think I would call it the piece of the archive tools that needs most attention
[22:10] <Logan_> I think it could benefit from some kind of joining of Ubuntu and Debian's removals.
[22:10] <cjwatson> IIRC Scott mostly wrote it while avoiding a team-building event, and then everyone else has just hacked it as they went :-)
[22:11] <Logan_> Also, I feel like Debian has to improve whatever script is generating that list.
[22:11] <cjwatson> Ubuntu's aren't exposed as a stream in the same way
[22:11] <cjwatson> I think Debian actually publishes deb822 removal files nowadays
[22:11] <cjwatson> But I haven't checked whether the data matches up and converted process-removals to it
[22:11] <cjwatson> That alone would be an improvement if possible
[22:12] <Logan_> Okay. I'll look into maybe converting the script to look at those.
[22:12] <Logan_> I have a good amount of Python knowledge, and this would be good practice. :P
[22:13] <cjwatson> It also has a problem where it tries to read the removals files incrementally, but sometimes this means that it times out in the middle of a giant run
[22:13] <cjwatson> It's all rather frustrating
[22:13] <cjwatson> Anyway, must go
[22:14] <Logan_> Alright, have a good one!
[22:14] <Logan_> Or maybe it could hook into MultiDistroTools.... Hm.
[22:15] <Logan_> Because the only removals we really care about are the ones that are currently in Ubuntu and not in Sid.
[22:18] <Logan_> That's something maybe you and wgrant could discuss.
[22:27] <wgrant> My mdt stuff used to do removal checking, but I think that's broken nowadays.
[22:27] <wgrant> Or we're up to date on Debian removals, but that seems unlikely.
[22:30] <stgraber> win 42
[22:35] <infinity> Logan_ / juliank: FWIW, I don't consider bugs with patches attached to be "mass bug filings", even if there are lots of bugs with similar topics.
[22:35] <Logan_> Yeah, that's the way I felt as well. But I'm not sure.
[22:36] <infinity> Logan_ / juliank: A muss bug filing is things like "we ran an automated checker on the archive and found 259 packages to be buggy, yours is one of them".
[22:36] <Logan_> So I shouldn't write to maintonly, right?
[22:36] <infinity> Logan_: IMO, no.  You're just filing bugs rapidly because you're fixing bugs rapidly, that't not the same as reporting en masse without fixes.
[22:37] <infinity> Logan_: And people who watch bugs-dist for patches they could sponsor or NMU might be interested in seeing your bugs, while they probably don't care about seeing 300 identical bugs with no patches.
[22:37] <Logan_> Good point.
[22:43] <juliank> infinity: Well, if he reports let's say 250 bugs in batches of 10 each, I'd consider that a mass bug filing, or at least close too, and I would ask before doing it.
[22:44] <juliank> But I don't really care that much (I only noticed it, because I my IRC client notifies me whenever someone mentions dh-autoreconf somewhere, and the bugs do, and I see them in #debian-devel-changes).
[22:45] <juliank> I'd like to know before someone introduces support for a new architecture in packages.
[22:49] <juliank> At least a short notice would be nice. I also don't see anything on<EMAIL_ADDRESS>and I think it would be reasonable to write something to them before doing this.
[22:50] <Logan_> juliank: I'm afraid I don't understand. Am I supposed to get permission before fixing FTBFSes on new architectures?
[22:50] <infinity> juliank: debian-powerpc has nothing to do with this, really.
[22:51] <infinity> And, yeah, I don't see why anyone would need notice before including support for a new arch.
[22:51] <infinity> (And, in the case of most of these, it's just generic future-proofing, not necessarily just for one arch)
[22:51] <infinity> Logan_: Wow, that dsc-statistics failure is... Weird.
[22:52] <Logan_> Tell me about it.
[22:52] <Logan_> That's the "changed too much" one, right?
[22:52] <infinity> Yeah.
[22:52]  * Logan_ shrugs.
[22:52] <Logan_> I personally would never use wdiff to determine whether or not a package will fail to build. :P
[22:53] <infinity> Seen on m68k too.
[22:53] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699917
[22:53] <infinity> Bizarre.
[22:54] <infinity> I might look at that one later out of sheer curiosity.
[22:54] <juliank> Well, for one thing, it is a bit uncoordinated this way. Now you have multiple bugs adding ppc64el support, and no way to find them. That's why I proposed contacting someone before, so that amongst other thing maybe the bugs can get a proper usertag saying that they are ppc64el bugs.
[22:55] <Logan_> Okay, I see where you're coming from on that side of things.
[22:55] <infinity> juliank: The way to coordinate them would be with usertags.
[22:55] <juliank> That's what I wrote.
[22:55] <infinity> No need to contact anyone in advance to create a tag.
[22:55] <juliank> Right, but clearly nobody thought of this yet...
[22:56] <infinity> But, like I said, most of these are actually generic.
[22:56] <infinity> At least, the autotools-dev and autoreconf ones are.
[22:56] <infinity> It's just generic "please future-proof your packaging" not "please add support for an arch".
[22:56]  * infinity shrugs.
[22:57] <Logan_> For the config.{sub,guess} ones, I just say "please use autotools-dev to update config.{sub,guess} for new arches"
[22:57] <juliank> infinity: Most packages explicitely do not use dh-autoreconf by default, they only use it, when they change files.
[22:57] <Logan_> Because it's not limited to ppc64el and arm64 support. Future rebuilds will allow support for more arches.
[22:57] <infinity> juliank: I know that.  I also tend to agree with Colin on this point that that's wrong.
[22:58] <infinity> juliank: autoreconf on build is a *good* thing.  It makes sure the source actually works.
[22:58] <infinity> (Even outside the new arches argument)
[22:58] <Logan_> infinity: Have you seen the bug in Debian about doing autotools-dev and/or autoreconf by default?
[22:59] <infinity> Logan_: No, but I'd disagree with that.
[22:59] <Logan_> Same here. It creates too much overhead for package maintainers, especially if the package doesn't need libtool and/or config.{sub,guess} updates.
[22:59] <Logan_> But...
[22:59] <infinity> Logan_: Well, not sure I'd disagree with autotools-dev by default, but autoreconf needs fiddling too much to do it without testing.
[22:59] <Logan_> I think that it's not harmful to do autoreconf if it fixes an FTBFS on new arches.
[22:59] <Logan_> And to continue using it into the future until upstream updates its own files.
[23:00] <Logan_> But it should be done on a case-by-case basis.
[23:00] <Logan_> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733045 if you want to jump in. A Debian maintainer sent it to me.
[23:03] <infinity> Logan_: Nah, that report's just about autotools-dev, not autoreconf (despite a short derailing in the conversation), I'm totally fine with that.
[23:04] <infinity> Updating config.{sub,guess} automagically has pretty much proven to be 100% harmless.
[23:04] <infinity> Maintainers should, however, be invovled in choosing to autoreconf, and testing that it works when they do.
[23:04] <Logan_> Especially as new autotools versions come out.
[23:05] <infinity> Well, that too, but I was thinking the part where you might need --foreign, or to feed it a subdir argument, etc.  It's not easily detectable how to do it right automatically without some fiddling.
[23:10] <juliank> Anyway, I'm leaving now.
[23:10] <juliank> I don't want to spend my night discussing things
[23:10] <Logan_> I've clearly wasted every night of my life.
[23:11] <Logan_> I wish the FTBFS report sorted by dependency level. As in, the packages that are most depwaited show up at the top.
[23:12] <Logan_> It would make it easier to clear out this ppc64el mess.
[23:34] <infinity> Logan_: That might be a handy thing to try to create.  Could also be a nightmare. :)
[23:34] <infinity> Logan_: I assume there are still some arm64 dep chains to unwind too (though, most of your fixes are probably getting both at once).
[23:36] <Logan_> I'm targeting all of the lib* packages first because I figure those will be the most depwaited.
[23:36] <Logan_> Although a number of shared libraries don't have source packages that start with "lib." :(


[19:13] <nacc> cjwatson: does lp's git server support atomic pushes?
[19:15] <cjwatson> nacc: I haven't specifically tested it, but it should do; that basically just requires git 2.4
[19:15] <cjwatson> (and we have a version newer than that)
[19:16] <cjwatson> once we know that we can, we basically just hand off to git receive-pack
[19:16] <nacc> cjwatson: ok, was just wondering -- would help with something i'm fixing in the importer :)
[19:17] <nacc> cjwatson: thanks!
[19:17] <cjwatson> np