=== _salem is now known as salem_
=== salem_ is now known as _salem
[01:59] <dupingping> How to get window's full image in compiz plugin?
=== Guest81467 is now known as rcj
=== Malsasa_ is now known as Malsasa
[04:14] <darkxst> pitti, what is the best place for this to live? bug 1418262
[04:14] <ubottu> bug 1418262 in apport (Ubuntu) "apport hook to detect wayland sessions" [Undecided,New] https://launchpad.net/bugs/1418262
[04:14] <darkxst> I suppose debian would find that useful also
[06:02] <pitti> Good morning
[06:02] <pitti> darkxst: wonderful!
[06:04] <darkxst> pitti, yep I though so as well, seems a reasonable solution as well
[06:06] <pitti> darkxst: followed up to 1418262
[06:07] <darkxst> pitti, its kind of useless in weston
[06:07] <darkxst> thats just a reference compositor, don't think anyone is actually using it
[06:07] <darkxst> all of the wayland libraries are installed by default
[06:07] <darkxst> which only leaves maybe Xwayland
[06:08] <pitti> bdmurray: will do, thanks
[06:09] <pitti> darkxst: ah, is the complete rendering etc. done in the libraries?
[06:09] <pitti> darkxst: it doesn't matter if the package is installed by default -- the hook of course needs to actually do some runtime detection (I left that out in the comment, I thought it was obvious)
[06:10] <darkxst> pitti, I think run-time detection is really hard, since there is no wayland server as such
[06:10] <pitti> darkxst: if all else is inappropriate we could also put it into apport, but I rather don't want to know about or maintain how wayland sessions are detected; that's something that a wayland packages are much better at
[06:11] <darkxst> wayland is basically a  set of libraries that define a protocol, the compositor becomes the server
[06:11] <pitti> darkxst: well, I can't believe that -- there must be *something* to tell a process that it can connect to wayland; the equivalent of $DISPLAY for X?
[06:11] <darkxst> pitti, as mentioned in the bug report, there seems to be a $WAYLAND_DISPLAY var
[06:12] <pitti> ah
[06:12] <darkxst> hopefully that is generic and not just a GNOME-ism
[06:12] <pitti> ah, and the wayland libs are synced with Debian
[06:13] <darkxst> pitti, and then there are other env vars that define (for GNOME) which backend is in use i.e wayland of Xwayland
[06:13] <darkxst> I assume apport reads the program env and not the gloval env?
[06:13] <pitti> darkxst: followed up again
[06:14] <pitti> darkxst: there is no "global" env; yes, you get the crashed program's env
[06:24] <darkxst> pitti, replied on apport bug
[06:25] <darkxst> and by global, I meant the users env
[06:26] <darkxst> but that doesn't matter it works as expected really
[06:27] <darkxst> so basically a tag, and perhaps including (GDK/CLUTTER)_BACKEND in the report if they are set as wayland is enough for us
[06:28] <darkxst> currently all GNOME apps run by default under Xwayland, unless the user explicitly requests wayland backend
[06:28] <darkxst> that I suspect will change in 3.16
[06:32] <alkisg> Good morning
[06:32] <pitti> darkxst: that sounds good
[06:32] <pitti> darkxst: so if you have a tested hook, I'll include it into the next apport upload
[06:33] <darkxst> pitti, I will write one, but not tonight, need to get back to painting
[06:34] <darkxst> should be pretty straight forward though, so in the next day or so
[06:34] <pitti> *od*
[06:34] <pitti> err, *nod*
[06:36] <alkisg> When an SRU is in the queue (specifically, update-manager in https://launchpad.net/ubuntu/precise/+queue?queue_state=1), is there something the reporter can do to speed up its review?
[06:42] <pitti> alkisg: not formally; you can ask SRU team members on IRC perhaps; often queue processing isn't done for longer periods of time, and then some poor soul comes along and processes them all in a big batch
[06:43] <alkisg> Thank you pitti... bdmurray, would you mind if I pinged you, since in the wiki it mentions your name for Thursdays? :-/
[06:45] <sarnold> in the past I've done the verification-done steps for other bugs that the package upload was affecting..
[06:45] <sarnold> granted, sometimes only the original reporter is in position to do that, but if you can reproduce the problem, it can help move things along; but I didn't see any outstanding verification-needed tags on the bugs
[06:46] <alkisg> I think that part comes after the upload to -proposed and before the upload to -updates... Now we're before the -proposed step
[06:46] <sarnold> ahh
[06:49] <darkxst> alkisg, see https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[06:49] <alkisg> darkxst, that's where I got bdmurray's name from :)
[06:50] <darkxst> alkisg, its early there, wait until later!
[06:50] <alkisg> Sure, np, thank you
[06:50] <darkxst> pitti is only up since he some sort of time freak ;)
[06:50] <sarnold> sure sign it's bed time when pitti joins :)
[06:51] <alkisg> Haha, I got up at 01:30 today, I'm sure I beat him
[06:51] <pitti> it's been a lot worse -- these days I sleep until 7!
[06:51] <pitti> alkisg: eww -- local time?
[06:51]  * alkisg wishes he could do that
[06:52] <alkisg> pitti: yes, usually I wake up around 4, but I'm probably getting the flu...
[06:53] <darkxst> pitti, 7 is a good time to wake up ;)
[06:53] <pitti> fully agreed :)
[06:53] <darkxst> should be much better than 5 or 6 you used to appear ;)
[06:54] <pitti> I'm sure I'll go back to that in summer
[06:54] <darkxst> is that all it is, too cold!
[06:54] <pitti> too dark
[06:55] <darkxst> opposite to my problem, too light to sleep in
[06:55] <pitti> I guess that's due to being on opposite hemispheres :)
[06:56] <darkxst> more a lack of blinds I think!
[06:57] <pitti> oh yeah! great invention that
[06:58] <darkxst> pitti, I have spent the last 3 months building this studio apartment but its still a WIP
[06:58] <darkxst> don't to the final bits though
[06:58] <darkxst> down even
=== marcust__ is now known as marcustomlinson
[06:59] <darkxst> hence no blinds!
[07:06] <infinity> arges: No objections, was going to do it today.
[07:07] <Noskcaj> How come python-click hasn't synced from unstable? It's got no ubuntu delta
[07:07] <infinity> smoser: I don't speak (or use) virsh.  Which bit am I looking at?
[07:08] <darkxst> infinity, will there be respins of trusty for -proposed bug>
[07:08] <pitti> Noskcaj: it's a new package, that doesn't happen automatically
[07:08] <infinity> smoser: "<topology sockets='1' cores='160' threads='1'/>" looks wrong, though.  Looks like you didn't disable SMT on the host.
[07:08] <pitti> Noskcaj: do you need it?
[07:09] <infinity> darkxst: We're not even remotely close to releasing today, proposed will be off before candidates happen.
[07:09] <infinity> darkxst: By "not close to releasing today", I mean "we'll slip for a week, probably", but we haven't sorted a date yet, and thus not communicated it.
[07:09] <darkxst> infinity, I have no clue what is happening since there seems to have been zero communication to the flavours ;(
[07:10] <infinity> pitti: python-click was blacklisted by cjwatson, IIRC.
[07:10] <darkxst> infinity, it would be nice to be kept in the loop!
[07:10] <pitti> infinity: ah, to not potentially collide with our click source?
[07:10] <infinity> darkxst: Right, I should have sent out a "we're delaying it, but not sure how long" email, I guess.
[07:10] <infinity> pitti: Something like that.
[07:10] <darkxst> I did expect delays given how late the lts stack landed, however seen nothing official
[07:10] <infinity> Package: python3-click
[07:10] <infinity> Source: click
[07:11] <pitti> ah, heh
[07:11] <pitti> here we are, two packages using common English words without a proper noun :)
[07:12] <darkxst> infinity, all the flavours (probably) have their testers firing into action for a release tomorrow
[07:12] <infinity> darkxst: Yeah, I should get a mail out ASAP.  I've mentioned the delay in passing on #-release, but not formally.  Sorry about that.
[07:12] <darkxst> not that extra testing is a problem, but you know!
[07:13] <darkxst> infinity, I may have seen comments hinting at that, but it wasn't concrete
[07:13] <infinity> darkxst: Yeah, I didn't think anyone in the community would complain about having extra time, but obviously it sucks to *waste* your time, too.
[07:13] <darkxst> I recall a 'might slip by a week, but I don't intend for that to happen?'
[07:14] <infinity> darkxst: Oh, that was a couple weeks ago.  Reality and my intent didn't align, clearly. :P
[07:14] <infinity> darkxst: Just landed the HWE stuff too late to have confidence in twiddling it all in place without error.
[07:15] <darkxst> infinity, yes I noticed that, very clearly
[07:16] <darkxst> and really I couldn't care if its delayed by however long, but these things need to be comminucated to the flavours QA teams
[07:16] <darkxst> and not just in hints!
[07:27] <slangasek> xnox: have you looked at how edk2 might be cross-buildable?  I haven't found the magic setting in the convoluted build system yet
=== kickinz1|afk is now known as kickinz1
[07:31] <Noskcaj> pitti, I' m assuming it fixes the FTBFS
[07:31] <pitti> Noskcaj: of what?
[07:31] <Noskcaj> of python-click
[07:32] <pitti> Noskcaj: we don't have that package in ubuntu at all
[07:32] <Noskcaj> https://launchpad.net/ubuntu/+source/python-click
[07:32] <Noskcaj> It says vivid-proposed
[07:33] <pitti> Noskcaj: ah, and supposedly cjwatson blacklisted it afterwards, so I guess we should just remove it again
=== work_alkisg is now known as alkisg
=== work_alkisg is now known as alkisg
[07:59] <slangasek> xnox: n/m, I seem to have figured it out... apparently you get to specify 'ARMGCC' if you want cross-build support ;P
[08:05] <dholbach> good morning
=== mthaddon` is now known as mthaddon
[09:30] <cjwatson> pitti,Noskcaj: I removed it, but I think I must have got unlucky with timing or something.  Removed again.  Not much to be done about it unless click is renamed
=== kickinz1 is now known as kickinz1|afk
=== alkisg is now known as work_alkisg
=== kickinz1|afk is now known as kickinz1
=== Malsasa_ is now known as Malsasa
=== kickinz1 is now known as kickinz1|afk
=== doko_ is now known as doko
=== _salem is now known as salem_
=== kickinz1|afk is now known as kickinz1
=== Malsasa is now known as Guest73507
=== Malsasa_ is now known as Malsasa
=== MacSlow is now known as MacSlow|lunch
[12:36] <flexiondotorg_> Trevinho, Are you about
[12:36] <Trevinho> ehm? :o
[12:37] <flexiondotorg_> Trevinho, Do you remember we spoke about me adding MATE support to Compiz?
[12:38] <Trevinho> flexiondotorg_: yep
[12:38] <flexiondotorg_> Trevinho, I've made a merge proposal.
[12:39] <flexiondotorg_> https://code.launchpad.net/~ubuntu-mate-dev/compiz/compiz-mate/+merge/248684
[12:39] <Trevinho> col
[12:39] <Trevinho> cool
[12:39] <flexiondotorg_> I'd really like to ship Ubuntu MATE 15.04 with Compiz.
[12:39] <flexiondotorg_> But I realise feature freeze is fast approaching.
[12:39] <flexiondotorg_> Any chance you'll have the time to review that?
[12:40] <Trevinho> flexiondotorg_: I'm on it
[12:40] <flexiondotorg_> Trevinho, I've been building a version of Compiz in my PPA, so it has been tested.
[12:40] <flexiondotorg_> Trevinho, Thanks!
[12:45] <Trevinho> flexiondotorg_: would be possible to share some of the code of the mate integration plugin with the gnome one?
[12:45] <Trevinho> flexiondotorg_: so something like a private lib
[12:45] <Trevinho> or even a plugin with gsettings stuff
[12:51] <flexiondotorg_> Trevinho, possibly. You'd know better than me.
[12:52] <flexiondotorg_> Trevinho, I just took the gnome stuff and adapted it. The only other thing I did was to remove Unity and HUD from the mate integration.
[12:52] <flexiondotorg_> Trevinho, I'm travelling this week. And need to go to a conference now. But post here and I'll read the backlog.
[12:54] <flexiondotorg_> Trevinho, Would is be possible to merge what I have now and then look to refactor it in a future merge proposal.
[13:09] <tkamppeter> doko, it is about the new HPLIP package and the pointer warnings. Can this build error be overridden, as the code affected is only for memory card readers in VERY old HP inkjets. Printing, scanning, fax and all less than ~8 years old devices are not affected.
[13:16] <cjwatson> No, the error can't be overridden.
[13:16] <cjwatson> tkamppeter: ^-
[13:16] <cjwatson> It's pretty much never hard to fix.
[13:18] <cjwatson> You're probably just missing an #include <Python.h> or some such.
[13:26] <Trevinho> flexiondotorg_: in case yes, hopin there's a future one :)
[13:47] <arges> infinity: ok i'll let you practice your typing skills to sru-release those things.
[13:51] <aeoril> I am working on Bug 1417978 <1417978@bugs.launchpad.net> I have verified that the bug no longer happens in today's daily build of vivid.  I the bug happens in trusty (14.4).  I need to see if it happens in utopic (14.10).  However, whenever I go look around at cdimage.ubuntu.com, I cannot seem to find any binaries for 14.10 for PC (just powerpc mac).  How do I find the x64 binary for
[13:51] <aeoril> Utopic (14.10) to try this out on?
[13:51] <ubottu> bug 1417978 in vim (Ubuntu) "vim improperly displaying text when loaded in gnome-terminal with altered geometry" [Undecided,New] https://launchpad.net/bugs/1417978
[13:52] <aeoril> Noskcaj darkxst ^
[13:55] <aeoril> Noskcaj darkxst I found it on the normal download page, but would still like to know where it is on cdimage.ubuntu.com
[13:55] <Laney> aeoril: it's on releases.ubuntu.com
[13:55] <aeoril> Laney Thanks!
[14:01] <aeoril> Laney I guess I am "triaging" this bug I made - however, I have never done that before.  Noskcaj and darkxst were helping me.  I verified it works fine in vivid, and am now checking previous releases to see where it was fixed and if it needs to be backported.  Is that the right thing to do at this stage?  I believe that 14.04.1 is being updated to 14.04.2?  How do I find the daily build
[14:01] <aeoril> for 14.04.2?  Or whatever the latest work on the update/upgrade to 14.04.1 is?
[14:01] <aeoril> Laney also, I was thinking of getting the latest version of VIM to try on 14.04.1 to see if it works?
[14:03] <aeoril> Laney also, I need someone to verify separately that it does not work as I say on 14.04.1/14.04?
[14:03] <aeoril> (confirm)
=== marcusto_ is now known as marcustomlinson
=== MacSlow|lunch is now known as MacSlow
[14:34] <jdstrand> hallyn: ok, I think you are going to need to update /etc/apparmor.d/abstractions/libvirt-qemu to strip out the deny rules (or change the tmp dir and add new rules for it) in at least the setUp()s of the failing tests. test_CVE_2010_2239() did something similar conditional on karmic. This would have to be conditional on vivid and whatever SRUs this change went into
=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
[15:11] <bluefoxxx> Hello!
[15:12] <bluefoxxx> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361954
[15:12] <ubottu> Debian bug 361954 in wnpp "RFP: ossec-hids -- Host-based intrusion detection system" [Wishlist,Open]
[15:12] <bluefoxxx> This stalled out in 2011, after good progress.
[15:12] <bluefoxxx> I would like to see the ossec-hids packages in Ubuntu by 16.04 LTS, but that requires packaging in debian upstream.
[15:12] <bluefoxxx> How do I file this on Launchpad?
[15:13] <bluefoxxx> Do I file a bug, linking to Debian bug #361954?  Or is there some other process to follow?
[15:13] <ubottu> Debian bug 361954 in wnpp "RFP: ossec-hids -- Host-based intrusion detection system" [Wishlist,Open] http://bugs.debian.org/361954
[15:13] <bluefoxxx> ubottu is pretty smart
[15:13] <ubottu> bluefoxxx: I am only a bot, please don't think I'm intelligent :)
[15:13] <cjwatson> if it's done in Debian in time then it'll hit Ubuntu automatically
[15:14] <cjwatson> it's not obvious what you gain by filing a Launchpad bug
[15:14] <bluefoxxx> It stalled in 2011; it's not getting done unless someone with technical capability to finish and maintain it also has stake in finishing it
[15:16] <hallyn> jdstrand: ok, thanks
=== matsubara is now known as matsubara-lunch
[15:32] <bdmurray> pitti: do you have any plans for a Vivid release of apport? I'd like to SRU the fix for bug 1084979.
[15:32] <ubottu> bug 1084979 in apport (Ubuntu) "Submitting error report asks confounding questions" [Medium,Fix committed] https://launchpad.net/bugs/1084979
[15:32] <xnox> infinity: yo, is C.UTF-8 thing an ubuntu one, or is it upstream now?
[15:33] <xnox> what needs to be done to get it upstream? I'm interested to do that.
[15:34] <infinity> xnox: It's Debian/Ubuntu, but we're sorting out how to make it upstreamable.
[15:34] <infinity> xnox: Which probably needs a rewrite to make it not a separate locale.
[15:35] <xnox> infinity: yeah, ideally it needs to be a "builtin" like C is.
[15:35] <xnox> infinity: who is "we" in "we're" above?
[15:36] <infinity> xnox: Me, Aurelien, and Carlos have discussed it off and on.
[15:36] <infinity> xnox: What's your motivation?  Just being able to rely on it existing on all distros?
=== kickinz1 is now known as kickinz1|afk
[15:36] <xnox> infinity: in /my/ distro.
[15:36] <infinity> xnox: Your distro being? :P
[15:36] <xnox> infinity: let's pretend it's ubuntu.
[15:37] <infinity> xnox: You're in luck, it's already in Ubuntu!
[15:37] <xnox> infinity: not really, it's in ubuntu patches, i want it upstreamed.
[15:37] <infinity> xnox: Anyhow, it'll never be backported to, say, RHEL7, but we're certainly working to have it uptreamed long before there's another RH. :P
[15:37] <xnox> infinity: cause honestly using ubuntu's glibc patches on ubuntu would be crazy =)
[15:38] <infinity> xnox: It's in Debian patches, not Ubuntu patches!
[15:38] <xnox> infinity: potato
[15:38] <infinity> potahto
[15:38] <xnox> infinity: anyone, let me be your monkey, tell me what needs done to get it sorted into builtin "C.UTF8" given how littel i have touched of glibc codebase.
[15:39] <xnox> s/anyone/anyway/
[15:39] <infinity> xnox: I feel like telling you would be about as much time as writing the patch.
[15:39] <xnox> infinity: sure, but without telling the design plan, it's never going to happen.
[15:39] <xnox> like console-setup/initramfs-tools merge
[15:40]  * xnox knows infinity better =)
[15:40] <infinity> xnox: Did I just hear you volunteer to do the console-setup merge?
[15:40] <infinity> xnox: slangasek will be thrilled to have it off his plate.
[15:40] <xnox> infinity: tough chance, i've assigned that as a work item to steve to sort out.
[15:40] <infinity> slangasek: ^ xnox wants to merge console-setup.
[15:40] <slangasek> heh
[15:40] <slangasek> infinity: but you wanted to review my partial merge :)
[15:41] <xnox> it's a blocker to move systemd =)
[15:41] <slangasek> xnox: I have the merge done but there are Ubuntu-specific installer integration bits that need forward-ported (the SKIP handling)
[15:41] <infinity> Ahh, right.
[15:41] <infinity> slangasek: Yes, I can review and sort those bits.
[15:41] <xnox> slangasek: i can do installer changes.
[15:41] <slangasek> lp:~vorlon/console-setup/1.108-merge-mach-2/
[15:41] <xnox> slangasek: what needs doing?
[15:41] <infinity> slangasek: This conversation is coming back to me now.
[15:42] <slangasek> xnox: no, this is the changes to the installer bits within console-setup
[15:42] <xnox> infinity: or will you?
[15:46] <infinity> slangasek: That's... An impressive delta.
[15:47] <slangasek> infinity: yeah.  mostly because of gratuitous changes on the Debian side :-P
[15:47] <slangasek> but a lot of this stuff should clearly be getting upstreamed
=== slangase` is now known as slangasek
[15:56] <smoser> slangasek, if you get a chance could you take a quick look at bug https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1418568
[15:56] <ubottu> Launchpad bug 1418568 in cloud-initramfs-tools (Ubuntu Precise) "depends on cloud-utils without knowledge of cloud-image-utils" [Medium,Confirmed]
[15:57] <smoser> comment 1 should give you enough information... my question is if there is something i can do to the cloud-tools archive packages to make this work (ie, fix without SRU of cloud-init)
[15:58] <slangasek> smoser: where does the cloud-image-utils package live? cloudarchive?
[15:58] <smoser> yes. its just a backport of trusty level of cloud-utils
[15:58] <slangasek> smoser: have you tried making cloud-image-utils in the cloud archive Conflicts/Replaces/Provides cloud-utils?
[15:58] <smoser> well it does conflict
[15:59] <slangasek> those weren't alternatives, I mean have you made it declare all three relationships on cloud-utils
[15:59] <smoser> also note the other removal (cloud-intiramfs-growroot) which depends on cloud-guest-utils.
[15:59] <smoser> cloud-utils from precise was later split into cloud-utils (meta package), cloud-guest-utils, cloud-image-utils
[15:59] <slangasek> mm
[16:00] <slangasek> is that cloud-utils metapackage also in the cloud archive?
[16:00] <smoser> yes. but juju would like to declare the smaller dependency chain in cloud-image-utils in later releases.
[16:00] <slangasek> yes but that shouldn't matter
[16:01] <smoser> no? its juju's request to install cloud-image-utils that causes the problem.
[16:01] <slangasek> installing cloud-image-utils from the cloud archive should pull in the cloud-utils package from the cloud archive, not remove the one from the main archive; unless the cloud-utils/cloud-image-utils relationships are buggy
[16:02] <smoser> hm.. maybe the dependencies are buggy.
[16:02] <slangasek> smoser: your cloud-image-utils/cloud-guest-utils should declare Breaks: + Replaces: for this case, not Conflicts:
[16:02] <slangasek> if you fix that, you /should/ get the desired results
[16:03] <slangasek> but see the advice in policy about not having versioned conflicts
[16:04] <smoser> ok. thanks. i'll look at that.
[16:08] <smoser> slangasek, http://paste.ubuntu.com/10075299/ thats the debian/control of cloud-utils in trusty (which would go back to cloud archive)
[16:08] <slangasek> smoser: Breaks/Replaces, *not* Conflicts/Replaces
[16:09] <smoser> yeah. thanks. i'll test.
=== marcusto_ is now known as marcustomlinson_
[16:43] <xnox> didrocks: transient presets are on the mailing list.
[16:44] <xnox> didrocks: for the time being i'm not interested in /dev/null symlinks.
[16:44] <xnox> diddledan: as one can do "echo disable foo.service" >> /etc/systemd/system-preset-transient/00-local.preset
[16:45] <xnox> didrocks: to override the "distro" transient-presets.
[16:45] <xnox> diddledan: unping
[16:45] <didrocks> xnox: seen that, I saw that you didn't really wanted to send it yourself first before I discussed it on the ML
[16:46] <didrocks> xnox: as I spent quite some hours with various people to discuss solutions
[16:46] <didrocks> let's see, I hope that's not going to put some issues for the debian integration
[16:46] <didrocks> but that's just not really cool, as I warned you at the sprint already about this…
[16:47] <xnox> didrocks: it is very generic thing, disabled by default, and has a lot of room to be improved/modified.
[16:47] <xnox> or semantics changed.
[16:48] <xnox> didrocks: in a sense this is first prototype one can start playing around with.
[16:49] <didrocks> yeah, let's see, I'll review it on the upstream ML, I'm just done with the fsck thingy
[16:49] <didrocks> implementing plymouth protocole manually btw
[16:49] <xnox> cool.
[16:50] <xnox> didrocks: well, we'll see what happens. I've tried to make the cover letter sound very open-ended and point out that this is not yet complete solution.
[16:50] <xnox> complete solution, for anyone, that is.
[16:51] <didrocks> xnox: just weird that you didn't mention that it was based on what we discussed as a comity during the hackfest
[16:51] <didrocks> but ok
[16:52] <didrocks> committee*
[16:58] <xnox> didrocks: i did mention hackfest.
[17:00] <xnox> no idea what a "comity" is.
[17:00] <barry> smoser: any status on py3 cloud-init?
[17:00] <smoser> its on the todo list.
[17:01] <smoser> i did some owrk on the non-python parts that you hadnt touched.
[17:01] <smoser> i'll work some more today on it.
[17:01] <barry> smoser: sounds good, thanks
[17:17] <bdmurray> cjwatson: is there any way to manually resolve Contents.gz being out of date when we encounter bug 1384797?
[17:17] <ubottu> bug 1384797 in Launchpad itself "Contents generation races with publisher" [Low,Triaged] https://launchpad.net/bugs/1384797
[17:18] <cjwatson> nothing really apart from fixing that bug
[17:19] <cjwatson> I did get started on that a while back but haven't had the time to finish - I was up to http://paste.ubuntu.com/10076288/, don't remember the state in detail
[17:19] <cjwatson> if I get time away from huge test suite of hugeness tomorrow I'll see if I can get back to that
[17:20] <bdmurray> cjwatson: okay, thanks
=== roadmr is now known as roadmr_afk
=== matsubara-lunch is now known as matsubara
[17:42] <ki7rw> i'm just curious as to what's the difference between lm-sensors4 and lm-sensors? sensors-detect doesn't work until i install lm-sensors (lm-sensors4 was previously installed) - ubuntu 14.04 64 bit
[18:49] <tjaalton> smoser: hey, commented #1418568 since it needs the sru header ;)
[18:49] <tjaalton> so if you're available to do that now then we can accept the upload
[18:49] <smoser> tjaalton, sweet. i will do that quickly.
[18:50] <tjaalton> cool
[19:01] <smoser> tjaalton, done
[19:01] <smoser> thank you!
[19:02] <tjaalton> thx :)
=== roadmr_afk is now known as roadmr
=== saurik_ is now known as saurik
[20:53] <hallyn> hi - bug 1418664 , what usually causes the error message "package is in a very bad inconsistent state;" ?
[20:53] <ubottu> bug 1418664 in cgmanager (Ubuntu) "package cgmanager 0.32-4ubuntu1 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration" [Critical,Incomplete] https://launchpad.net/bugs/1418664
[21:15] <mihok> I'm having trouble getting blah.links to do.. anything? I thought once I packaged the folder in .deb it would automagically create symlinks for my package when installed?
[21:16] <mihok> also some tutorials show use of a debian/ folder, others show DEBIAN/, which is correct?
[21:17] <tarpman> mihok: debian/ is in the source package and you maintain it; DEBIAN/ is in the binary packages and is (typically) generated by the build tools
[21:18] <mihok> tarpman, ah thanks, what if my binary is really just a bash script?
[21:19] <tarpman> mihok: sorry, I don't understand the question
[21:19] <cjwatson> then that just means you skip the "compile stuff" step
[21:19] <cjwatson> you still have a source package and a binary package
[21:20] <mihok> ah
[21:20] <cjwatson> blah.links is used by dh_link; ideally you're just using the short dh form based on /usr/share/doc/debhelper/examples/rules.tiny, which will run all the standard tools for you
[21:21] <cjwatson> I highly recommend reading the various debhelper man pages, they're very good
[21:21] <cjwatson> if you see any tutorial that spends any meaningful amount of time talking about DEBIAN/, discard it immediately and read something else
[21:22] <mihok> ah really
[21:22] <cjwatson> it's occasionally worthwhile to explain the internals of binary package building, but not in the context of a "how to package stuff" tutorial, and it's a good sign that the author is either rambling on about stuff you don't need to know, or is themselves terminally confused
[21:22] <mihok> I was assuming you could skip the 'source' step and just have it in binary form
[21:22] <cjwatson> in principle yes; in practice it's making trouble for yourself
[21:22] <mihok> right
[21:23] <mihok> makes sense, thanks
[21:24] <cjwatson> (there are lots and lots of "source" packages that consist only of interpreted code; but the source package format is still the one you want to use for version control, it lets you use the various tools for producing decent-quality binary packages with minimal effort, etc.)
[21:24] <mihok> off hand do you know of any tutorials that go through the whole process well? ive been finding some random ones that arent that good and going through the ubuntu packaging guide
[21:26] <cjwatson> the Ubuntu packaging guide is ok; https://wiki.debian.org/IntroDebianPackaging (less detailed) and https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf (more detailed, arguably too much) are decent too
[21:27] <cjwatson> though I'm afraid it's 15 years since I used a tutorial myself so I'm not sure I'm the best person to answer :)
[21:28] <mihok> no worries, thanks for your help though!
[21:28] <cjwatson> you could also take the approach of finding a simple package with a similar kind of structure
[21:29] <cjwatson> and apt-get source that and use it as a baseline
[21:29] <cjwatson> one of my own (not so much blowing my own trumpet, as this way I know what I'm suggesting) is "madison-lite", which is just a perl script (but the perl/shell distinction doesn't matter here except for a couple of extra entries in Depends) plus man page plus examples
[21:29] <mihok> oh cool I didnt know you could do that
[21:30] <cjwatson> so if that helps at all then feel free
[21:30]  * cjwatson -> pub
[21:31] <cjwatson> people here or on #ubuntu-packaging are likely willing to review a source package if it's stuck up on the internet somewhere, too
[23:43] <darkxst> aeoril, to backport the fix to 14.10 or 14.04 you would need to find the actual commit that fixed
[23:57] <aeoril> darkxst how would one do that? Trial and error?
[23:58] <darkxst> aeoril, search upstream bugtracker
[23:58] <darkxst> maybe search upstream git logs or whatever VCS they use
[23:59] <aeoril> darkxst I still need to verify vim was the problem, and not gnome-terminal or whatever ...
[23:59] <darkxst> as a last resort you could run a bisect
[23:59] <aeoril> darkxst I already talked with a guy over at #vim and he said they don't really have a bug tracking system