[04:21] <FourDollars> Why can we use some kind of suffix like 6.14.04.1 in https://launchpad.net/ubuntu/+source/partman-efi for trusty? In there any documentation for this kind of rule?
[05:05] <darkxst> FourDollars, the rule is that an SRU version can't conflict with any past or future versions of the package
[05:07] <FourDollars> darkxst: OK. So can I use 25ubuntu6.20151102.1 if the previous version is 25ubuntu6?
[05:09] <darkxst> FourDollars, well you could, but dates are usually used for vcs snapshots
[05:10] <FourDollars> darkxst: How about 25ubuntu6trusty1? Is it also valid?
[05:11] <FourDollars> darkxst: The precise version used 25ubuntu1.2 for 25ubuntu1. I am wondering why the trusty version used 25ubuntu6.14.04.1 for 25ubuntu6.
[05:11] <darkxst> FourDollars, well that would be greater than the version that copied into utopic, so no
[05:12] <darkxst> 25ubuntu6.14.04.1 or 25ubuntu6.1, would have been equally fine
[05:12] <darkxst> and they are the two most common forms of SRU versions
[05:13] <FourDollars> darkxst: I guess using 14.04 is to indicate this change is used for trusty, right?
[05:14] <darkxst> FourDollars, yes
[05:15] <darkxst> also if there had been a 25ubuntu6.1 in utopic before the trusty upload that could not have been used either
[05:16] <darkxst> that kind of situation would probably only happen with projects with dead or slow upstream releases though
[05:16] <FourDollars> darkxst: 25ubuntu6.14.04.1 is also greater than the version that copied into utopic. Why is it OK?
[05:18] <darkxst> FourDollars, sorry itss the other way around, you can't upload 25ubuntu7, because that would be a possible future version
[05:18] <darkxst> so  6trusty1 would be ok
[05:19] <FourDollars> darkxst: OK. I see. Thank you for your explanation.
[07:21] <dholbach> good morning
=== zyga-afk is now known as zyga
=== nudtrobert1 is now known as nudtrobert
=== hikiko__ is now known as hikiko
=== nudtrobert1 is now known as nudtrobert
[09:42] <Odd_Bloke> pitti: Xenial images for you to play with are at http://people.canonical.com/~dwatkins/20151028/
[09:42] <Odd_Bloke> :)
=== zyga is now known as zyga-afk
=== zyga-afk is now known as zyga
[11:58] <nikolam> Hi, shouldn't I have btrfs-tools with same version as the kernel in LTS? I have 3.19.0-31 kernel and 3.12-1 btrfs-tools and I am having an issue with very slow Btrfs send...
[12:01] <highvoltage> /win/win /win 26
[12:01] <highvoltage> (lol sorry)
[12:01] <ogra_> what a winner you are today :)
[12:01] <nikolam> winnner of windows 3.1 starting with win ?
[12:31] <Mirv> Laney: would the "Please add packages to qt5 package set" thread on devel-permissions need something more still.I did a proposal two weeks ago, but then obviously there was release rush etc so I can see why it'd be easily forgotten again.
[12:35] <Laney> Mirv: I don't remember, sorry, let me check on it shortly
[12:37] <Mirv> Laney: ok, thanks, no hurry
=== balloons is now known as Guest4533
=== Guest4533 is now known as ballons_
=== ballons_ is now known as balloons_
=== hikiko is now known as hikiko|ln
=== zyga is now known as watson
=== balloons_ is now known as balloons
=== hikiko|ln is now known as hikiko
[14:03] <seb128> hum
[14:04] <seb128> $ ./process-removals -s obexd
[14:04] <seb128> INFO:root:obexd (0.48-2.1): back in sid - skipping.
[14:04] <seb128> but no
[14:05] <seb128> $ rmadison -u debian obexd
[14:05] <seb128> obexd      | 0.28-1        | oldoldstable | source
[14:05] <seb128> obexd      | 0.46-1        | oldstable    | source
[14:05] <seb128> wth?
[14:08] <didrocks> Comment: (From Debian) ROM; obsolete; Debian bug #772094
[14:08] <ubottu> Debian bug 772094 in ftp.debian.org "RM: obexd -- ROM; obsolete" [Normal,Open] http://bugs.debian.org/772094
[14:08] <didrocks> Remove [y|N]?
[14:08] <didrocks> with process-removals here
[14:09] <didrocks> (I didn't accept yet, the warning is after it?)
[14:09] <cjwatson> seb128: you probably have an old cached Debian_something file in your current dir
[14:09] <cjwatson> process-removals is kinda ropey
[14:10] <didrocks> yeah, I check on my Sources.gz that were downloaded, no reference for sure
[14:10] <didrocks> seb128: want me to ack?
[14:11] <Laney> FourDollars: Do you have an XPS 13 with 14.04 on it to check the fix for https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1480217 ?
[14:11] <ubottu> Launchpad bug 1480217 in nautilus (Ubuntu Trusty) "Nautilus background handling screwed when changing scaling factor." [High,In progress]
[14:11] <seb128> didrocks, if you want
[14:11]  * didrocks flushes
[14:11] <didrocks> Laney: FYI ^
[14:11] <seb128> cjwatson, indeed I had, thanks for pointing that out
[14:12] <seb128> Laney, did larsu fix the icons issue as well now?
[14:12] <Laney> looks ok to me
[14:36] <cyphermox> good morning!
[14:42] <teward> does anyone know how apport / ubuntu-bug detects duplicate bugs?  Second related question is if it can detect duplicate package-type bugs based on a given signature...
[14:51] <seb128> slangasek, your python-pgmagick no change rebuild failed, the new version (pypi.debian.net/pgmagick/pgmagick-0.5.12.tar.gz) add compat for the graphicsmagick version if you want to do the update
[14:52] <slangasek> seb128: thanks, that build failure was on my list of things to look at
[15:02] <FourDollars> Laney: Yes, I have an XPS 13 with HiDPI screen.
[15:03] <Laney> FourDollars: with 14.04, right?
[15:04] <FourDollars> Laney: Let me check.
[15:05] <FourDollars> Laney: Yes, it is with 14.04.
[15:07] <Laney> FourDollars: ok, could you check with the debs in http://people.canonical.com/~laney/package-junkyard/ please?
[15:10] <dobey> teward: the bugs that apport marks as duplicate, matches the stack signature afaik
[15:11] <FourDollars> Laney: Yes, it seems to fix the issue.
[15:17] <Laney> FourDollars: thanks
[15:17] <FourDollars> Laney: np
[15:18] <davmor2> Laney: does that let me off the hook or do you want a second confirm?
[15:18] <Laney> davmor2: you can verify it from trusty-proposed later on if you want :P
=== lan3y is now known as Laney
=== RAOF_ is now known as RAOF
=== henrix_ is now known as henrix
=== beuno_ is now known as beuno
=== kenvandine_ is now known as kenvandine
[16:39] <dholbach> can somebody moderate my mail on u-d-a?
[16:54] <cjwatson> dholbach: done
[16:57] <dholbach> thanks cjwatson
[18:01] <teward> dobey: OK, so no way to make an apport bug detect something from the report attachments itself, then, to determine a duplicate...?
[18:01] <NikTh> Hello, anyone else getting similar errors ? https://launchpadlibrarian.net/224027178/buildlog_ubuntu-trusty-amd64.linux_4.3.0-00.201511021933_BUILDING.txt.gz
[18:02] <NikTh> Found this one, seems similar but... no coding here :-) https://lkml.org/lkml/2015/9/11/644
[18:02] <pitti> teward: there is; normally through the signature of the stack trace, but we also have plenty of "patterns" to match on e. g. dpkg log files or X.org logs
[18:03] <dobey> what pitti said
[18:03] <pitti> http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns/files
[18:03] <pitti> teward: ^
[18:04] <teward> pitti: does that work from output of commands done by package hooks?  The reason I've been asking is there is a *substantial* number of bugs being filed against 'nginx' for "Could not bind to *:80: Address in use" errors, and they come up in most of the bug reports seen.  Thanks to the apport hooks i can tell what causes the install/upgrade postinstall failure (it's that), but... trying to eliminate some work :p
[18:04] <teward> pitti: thanks i'll peek
[18:04] <pitti> teward: yes, on any field of the report, doesn't matter
[18:04] <sarnold> NikTh: maybe add libssl-dev to your Build-depends: line?
[18:04] <teward> pitti: OK, i'll start poking and peeking.  Thanks.
[18:05] <NikTh> sarnold: Thanks. Let me try.
[18:06] <sarnold> NikTh: (I haven't verified that that package has the file you need, it just doesn't appear in your build logs and seems plausible)
[18:07] <teward> sarnold: betcha it's openssl-dev not being installed.
[18:07] <teward> sarnold: apt-file shows openssl-dev as installing that file to /usr/include/openssl/opensslv.h so...
[18:07] <teward> (with regard to NikTh's issue)
[18:08] <teward> (at least in Trusty)
[18:08] <NikTh> sarnold: I have the trusty's config files as they are. I have changed nothing except adding my <e-mail> there (in control files)
[18:08] <sarnold> teward: heh, N: Unable to locate package openssl-dev
[18:08] <teward> oops
[18:08] <teward> libssl-dev
[18:08]  * teward yawns
[18:08] <teward> sarnold: E:NoCoffee
[18:08] <teward> :)
[18:08] <NikTh> haha :)
[18:08] <sarnold> :)
[18:08] <NikTh> Ok, libssl-dev it is, then. I will try this one. :)
[18:08] <teward> Thank goodness, coffee's here.  *steals a "Box o' Joe" and gets to developer work*
[18:19] <teward> pitti: so, then in the bug patterns XML file, key would be whichever item grabbed by the package hooks I want to look at, and regex-matching?  *trying to wrap head around the apport bug pattern detection*
[18:20] <pitti> teward: right; the README file hopefully explains the basics of it
[18:20] <teward> ok
[18:20] <teward> you know what the page didn't show me?  The README file
[18:20] <teward> >.<
[18:25] <teward> pitti: that reminds me, I have a typo in my package hooks... oops.
[18:25]  * teward should fix that xD
=== _salem is now known as salem_
[19:41] <teward> pitti: with regards to apport and duplicate detection, how does that work if we have different versions in different releases that will have different report data?  (Vivid+ has my apport hooks, Trusty and earlier don't and use different files for the data...)
[19:43] <pitti> teward: I guess you'd create two patterns, one for vivid+, one for trusty?
[19:43] <teward> ok
[19:44] <teward> works for me, for now i'll focus on vivid+ 'cause that's where the hooks exist, i'm still ironing out the trusty/precise ones.
[19:44] <teward> thanks
=== salem_ is now known as _salem
[20:00] <teward> pitti: would you be able to spot-check for blatantly obvious evil errors in my pattern that i've written locally?
[20:00] <pitti> teward: sure! pastebin the diff?
[20:01] <teward> will do shortly, in the middle of beating an nfs share 'cause i need the data there :P
[20:01] <sil2100> cjwatson: hey! So, would it be possible to move the LP weekly translation exports for ubuntu-rtm/15.04 a day later? (on Wednesdays) I remember the rationale for it being set for Tuesdays was that it's hard to schedule as normally those take a lot of time to create
[20:01] <sil2100> cjwatson: but the 15.04 ones actually build in 5-10 minutes
[20:01] <sil2100> cjwatson: you think that would be doable?
[20:07] <teward> pitti: i'm going to thoroughly test this of course but in the interim:  http://paste.ubuntu.com/13085614/
[20:08] <teward> my regex-fu is not super strong though
=== ddstreet_away is now known as ddstreet
[20:09] <pitti> teward: hm, that bug doesn't actually have a SystemctlStatusFull_Nginx.txt attachment, but I suppose one of the dupes
[20:10] <teward> pitti: no, that bug doesn't, it's the master
[20:10] <pitti> teward: ( and ) are magic in REs, so you need to escape them
[20:10] <teward> there's multiple dupes, I got tired of canned-responsing
[20:10] <teward> ok
[20:10] <teward> pitti: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1495805 is one of the 'dupes'
[20:10] <ubottu> Launchpad bug 1512344 in nginx (Ubuntu) "duplicate for #1495805 [Master Bug] Package nginx-* failed to install/upgrade due to Port 80 not being able to be bound to, due to "Address In Use" errors." [Undecided,Invalid]
[20:10] <pitti> teward: you can run ./test-local <supposed dupe> to make sure your pattern works
[20:10] <teward> OK
[20:11] <pitti> teward: so if you run it now against a dupe, it will most probably say that it didn't find a match
[20:11] <teward> pitti: i also have a typo in my apport hook which is going to be fixed soon so this is a 'testing first' before 'suggest inclusion' (gotta fix the apport hooks, gotta merge)
[20:11] <teward> pitti: ok.
[20:11] <teward> i'll do testing, but the blatantly obvious errors were the regex :)
[20:11] <pitti> teward: perhaps say "failed.*98: Address already in use" to avoid having to match the parentheses?
[20:12] <teward> mmm... that'd work.
[20:12] <pitti> teward: and then ./test-local should recognize it as a dupe
[20:23] <teward> will test that, thanks pitti
[20:25] <henrix> utlemming: the fixes for bug #1454758 have been applied to the Precise kernel, but it looks like they should actually be applied to the linux-backports-modules-3.2.0 instead.  could you confirm this?
[20:25] <ubottu> bug 1454758 in linux (Ubuntu Precise) "[Hyper-V] storvsc: Set the SRB flags correctly when no data transfer is needed" [Critical,Fix committed] https://launchpad.net/bugs/1454758
[20:25] <henrix> utlemming: (apw suggested me to ping you ;) )
[20:26] <henrix> utlemming: this caught my attention because this seems to break the -lbm build
[20:36] <teward> pitti: who has to do the review of a merge though, once I have this 'tested' and 'working'?  Do I just make a merge req?
[20:44] <sil2100> slangasek: https://bugs.launchpad.net/ubuntu/+source/hevea/+bug/1512467
[20:44] <ubottu> Launchpad bug 1512467 in hevea (Ubuntu) "Release no-change rebuild for ocaml transition" [Undecided,In progress]
[20:48] <teward> pitti: test-local's causing "file stream must be in binary mode" errors, 15.04 testing.  Passing it the path for the .crash file, is this normal?
[20:59] <sil2100> slangasek: thanks for sponsoring!
[21:00] <slangasek> sil2100: no prob
[21:03] <cyphermox> slangasek: should we be looking at the ocaml transition in particular?
[21:03] <sil2100> cyphermox: I'm working on that now
[21:03] <cyphermox> yeah
[21:03] <sil2100> Moving steadily with the bleh rebuilds
[21:03] <cyphermox> I know, that's why I'm asking; I think we want to avoid duplicating work, but there is a lot of ocaml anyway
[21:03] <sil2100> I might be done somewhere tomorrow since I want to spend most of my time there
[21:04] <slangasek> cyphermox: sil2100 is driving it, I don't know that it needs more eyeballs currently
[21:05] <cyphermox> slangasek: I figured; I picked $random !ocaml.
[21:05] <cyphermox> sil2100: are you using update-output-helper too?
[21:06] <sil2100> cyphermox: no, not sure if I know that one, I use chroots, check if it installs and why not and rebuild/fix
[21:06] <sil2100> I have a script that does the no-change rebuilds for me
[21:08] <cyphermox> sil2100: ok
[21:11] <teward> pitti: nevermind, i fixed it although I had to generate another bug to test it.  Looks like the pattern, with your help, matches and spits out the 'master bug' for the issue I created earlier today.  How do I go about getting it included in the apport patterns?
[21:11] <teward> (I'll upload a new branch just for that)
[21:15] <NikTh> sarnold: I've passed the error with openssl because of your suggestion and thanks. Any thoughts in the new error? http://pastebin.com/raw.php?i=6HM0WzCc
[21:16] <sarnold> NikTh: look higher up in the build log
[21:16] <NikTh> sarnold: if it matters this lines occur immediately after "  LD      drivers/built-in.o"
[21:16] <NikTh> these
[21:17] <NikTh> hmm, maybe I have to paste the full log ? I'm trying this local now (pbuilder)
[21:17] <sarnold> if it's immediately after the LD .. line then you may need to add V=1 to the top-level make command to figure out what exactly died
[21:18] <NikTh> sarnold: I will try this. Thanks.
=== evilnhandler is now known as nhandler
[21:54] <pitti> teward: re (sorry, meeting)
[21:54] <pitti> teward: just do an MP and I'll review/merge it
[21:54] <teward> pitti: OK, will do, gotta poke a few things
[21:54] <teward> pitti: the test-local doesn't work with .crash files though
[21:54] <teward> (see the error I said it printed earlier)
[21:55] <teward> in which case the 'usage' help on it should be updated perhaps
[21:55] <pitti> teward: no, just with LP bugs, as that's what it operates on
[21:55] <teward> OK
[21:55] <teward> pitti: (the actual executable says to pass it a .crash file path though or an LP bug)
[21:55] <pitti> teward: oh, ok; sorry, it's been ages since I've used it
[21:55] <teward> "Usage: %s <.crash file or bug number>", line 27 :)
[21:56] <teward> pitti: i'll have a bugpatterns update, but then i may go poking at the script, propose a few changes if it only works with LP bug numbers.
[21:56] <teward> give me a few minutes, gotta change wireless APs.
[21:56] <pitti> teward: that would be appreciated
[22:00] <teward> pitti: feel free to reject if the target bug is not satisfactory, I have another bug avaialble that can be the target.  Merge Req. against the bugcontrol repo, or the lp:apport project?
[22:02] <pitti> teward: against the branch you branched it off, i. e. the ubuntu-bugpatterns one
[22:02] <teward> ack
[22:03] <teward> pitti: https://code.launchpad.net/~teward/apport/ubuntu-bugpatterns-nginx/+merge/276471 is the merge, let me know :)
[22:03]  * teward has no issues if it's rejected
[22:05] <pitti> teward: pulled, thakns!
[22:07] <teward> eheheheheh, i spammed myself 'cause it's a bugcontrol branch xD
[22:07] <teward> pitti: thank you for pulling it in :)
[22:08] <teward> i appreciate all the help from you and others on the apport bug stuff (both the package hooks and the dupe detection)
[22:13] <teward> pitti: if I happen to update the report attachment name in Xenial (as a result of fixing a couple typos in my hooks), I assume i'll have to make an update to the bugpatterns?
[22:14] <pitti> teward: right; you should duplicate the entire pattern clause and adjust the key name if that changes
[22:26] <teward> pitti: it may or may not change, depends on whether the tiny typo (it duplicates the .txt extension twice on attachments) really irritates me that much :P
[22:26] <teward> i'll let you know when I have any such changes :)
[22:27] <teward> again, thanks for your help though :)
[22:27] <sil2100> Does anyone know who's the current maintainer of our transition tracker code? lp:ubuntu-transition-tracker
[22:27] <pitti> teward: the key="" value itself is not a re, the re matching applies to the contents of the key
[22:28] <pitti> teward: so this does need a new rule then
[22:28] <teward> ok
[22:28] <teward> pitti: right, i know it isn't a re, just wanted to make sure that's what I'd have to edit if i fix the typo in the hooks :)
[22:29] <teward> as it stands it's so minor that it's not really needing fixing - doesn't affect the report much
[22:31] <sil2100> slangasek, other-core-devs: could anyone sponsor https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1512502 for me?
[22:31] <ubottu> Launchpad bug 1512502 in llvm-toolchain-3.5 (Ubuntu) "Release no-change rebuild for ocaml transition" [Undecided,In progress]
[22:56] <slangasek> sil2100: done
[22:56] <sil2100> slangasek: thank you!
[22:57]  * sil2100 feels silly uploading so many no-change rebuilds
[22:57] <sil2100> Free karma I suppose
[22:57] <slangasek> ;)
[22:57] <Unit193> You know what they say about Karma...
[23:00] <NikTh> sarnold: If this helps you , because I cannot understand what is happening. http://pastebin.com/raw.php?i=f6sNZvEL
[23:02] <sarnold> NikTh: sorry, I can't spot anything unusual or incorrect
[23:02] <sarnold> NikTh: it's possible that the error is still earlier in the log, I guess
[23:05] <NikTh> sarnold: no problem. Thanks for all your help till here. Maybe it's my misconfiguration after all (in debian.master/ folder , because I've changed too many things there). I will try tomorrow again. bb.
[23:05] <sarnold> good luck :)
[23:34] <cjwatson> sil2100: I expect we can find some time when it won't collide with other things, but please could you remind me during the daytime or send me mail or something so I'll remember?
[23:34] <sil2100> cjwatson: sure! Thanks :)