[00:08] <ari-tczew> micahg, siretart: bug 706725
[00:21] <ari-tczew> mr_pouit: around?
[00:42] <ari-tczew> if package has got changed binary package, is enough to change depends and b-d in rdepends? or replace/conflicts also is needed?
[00:42] <persia> It depends entirely on what sort of binary package change happened.
[00:42] <persia> Do you have an example?
[00:43] <ari-tczew> hello persia
[00:44] <ari-tczew> yes, example: http://paste.ubuntu.com/557454/
[00:44] <ari-tczew> I'm reviewing one sync request which looks small, but it's require a lot of transitions due to some syncs from experimental.
[00:45] <ari-tczew> looks like gigantic work
[00:46] <persia> Ugh.
[00:46] <persia> I generally dislike single source packages providing multiple libraries, and further dislike versioned -dev packages.
[00:47] <persia> But if that's what you7re starting with, you'll also need to adjust the shlibs (and potentially symbols) files, so that things built against it end up with the right dependencies, and then probably rebuild (and likely port) all the rdepends.
[00:49]  * micahg would suggest waiting for Debian to port the rdepends unless there's a pressing reason
[00:49] <persia> Might be done.  Might be relatively easy to port (and Debian/Upstream would appreciate porting patches).
[00:50] <persia> But, yeah, since we're past DIF, probably only worth it if there's some important change.
[00:56] <ari-tczew> micahg, persia: mission failed. getting through the string to the ball, at the end I got: dh_makeshlibs: dpkg-gensymbols -plibgwengui-fox16-0 -Idebian/libgwengui-fox16-0.symbols -Pdebian/libgwengui-fox16-0 returned exit code 1
[00:56] <ari-tczew> too much work
[00:56] <persia> DId you update/change all the symbols files for all the libraries?
[00:57] <ari-tczew> persia: I'm only building experimental packages on my pbuilder-natty.
[01:00] <ari-tczew> FYI, bug 706645
[01:01] <ari-tczew> I can imagine how much rebuilds and transitions will needs Ubuntu 11.10.
[01:01] <ari-tczew> I guess that many libs and important software will be upgraded after Debian 6.0 release like perl 5.12, openssl 1.0
[01:02] <ari-tczew> and viele viele mehr
[01:02] <micahg> ari-tczew: if we can get stuff sync'd with unstable, most of it will happen automatically
[01:02] <micahg> s/will/should/
[01:02] <persia> Yeah.  Once Debian releases, we'll probably want to mostly cherrypick, rather than syncing for natty.
[01:03] <micahg> yeah, I meant sync'd with pretransition versions :)
[01:04] <ari-tczew> micahg: I wish that will be automatically. If it's true that Debian will be released in the 1st half of February, then they have a time to adjust archive since out next devel open - May - June.
[01:04] <ari-tczew> s/out/our
[01:05] <ari-tczew> does anybody know how long adjust toolchain is taking for Debian?
[01:05] <ari-tczew> I;m asking due to curiosity.
[01:07] <ari-tczew> micahg: btw. today reviewing libgpg-error is time-consuming for me. let alone about that much transitions as we've discussed some minutes ago!
[01:07] <kklimonda> out of curiosity :)
[01:07]  * kklimonda would love to have others point out his grammar mistakes more often.
[01:08] <persia> "due to curiosity" is grammatical, if less common
[01:08]  * micahg keeps that in mind :)
[01:08] <kklimonda> persia: really?
[01:08] <kklimonda> thanks, good to know
[01:08] <ari-tczew> what's wrong?
[01:08] <kklimonda> ari-tczew: nothing :)
[01:09] <ari-tczew> ok
[01:09] <kklimonda> persia: it can be used in the same context as "out of curiosity"?
[01:09] <persia> I suppose.  It isn't usually.
[01:09] <ari-tczew> out of curiosity = 0 curiosity
[01:09] <ari-tczew> due to curiosity = a lot of curiosity :>
[01:10]  * ari-tczew feels pretty sick. :-/
[01:11] <micahg> ari-tczew: no, out of curiosity means that curiosity exists, basically the same thing as due to curiosity colloquially
[01:11] <persia> kklimonda, "Colorless green ideas sleep furiously" is grammatical as well: don't fall into the trap that everything grammatical is good: usage is important.
[01:11] <kklimonda> persia: I missed you :)
[01:11] <persia> http://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously
[01:14] <RAOF> persia: So, what we need is a language where only correct statements are grammatical :)
[01:14] <ari-tczew> micahg: OK kklimonda explained me via PM about special case for "out of curiosity"
[01:49] <ari-tczew> bdrung: why kubuntu.org is not supported by update-maintainer?
[01:53] <persia> Because the packages *should* all have "Ubuntu Developers<EMAIL_ADDRESS>as the maintainer, which doesn't include that string.  Anything else encourages separatism.
[01:54] <ari-tczew> persia: maintainer with @ubuntu.com is wrong?
[01:55] <persia> It's suboptimal.  Anything other than the string above implies that that package should only be modified by some subset team, rather than all developers.
[01:55] <persia> This is an exclusionary statement, something we try to avoid.
[02:07] <kklimonda> oh great, looks like libevent transition is going to be a pure joy
[02:08] <kklimonda> the 2.0.10 version have a versioned library, but puts headers in the same location as 1.4.x..
[02:09] <RAOF> That sounds pretty standard.
[02:10] <kklimonda> RAOF: but now we can't really update libevent to 2.0.10 until all applications that are using 1.4.x aren't ported, right?
[02:10] <RAOF> Yes.
[02:11] <Rcart> Hello everyone. Which deb3 fields are more common used in a patch?
[02:12] <kklimonda> RAOF: well, that doesn't sound standard to me.. and to think that just few months back I was asking why are gtk headers versioned.. :)
[02:12] <paultag> Rcart: deb3 or dep3 ?
[02:12] <Rcart> paultag: Sorry, dep3 (:
[02:12] <RAOF> kklimonda: It's what often happens, which makes it fairly standard :)
[02:12] <paultag> Rcart: :)
[02:13] <paultag> Rcart: what ever feels right. There are some that make sense, others that really would only apply to stuff such as the linux project
[02:13] <paultag> Rcart: I use different tags ( most the time ) then others because of my workflow
[02:13] <paultag> Rcart: it's status upstream, description and author are usually common
[02:15] <kklimonda> I use Description, Origin, Forwarded (if Origin != upstream) and Bug-(Debian|Ubuntu)
[02:15] <paultag> +1
[02:16] <paultag> today was a great day. I got rid of most of my patches :)
[02:17] <paultag> God, I hate patches so much. They just fester and clot up the code base
[02:17] <Rcart> Ok, thanks paultag and kklimonda :)
[02:17] <paultag> good luck Rcart!
[02:19] <ari-tczew> I know why Rcart is asking about DEP3 :)
[02:19] <paultag> ari-tczew: yeah?
[02:19] <Rcart> ari-tczew: o/
[02:19] <ari-tczew> paultag: IIRC I suggested him to add to his patch.
[02:19] <ari-tczew> Rcart: hello
[02:19] <paultag> ari-tczew: ah. gotcha
[02:21] <Rcart> ari-tczew: i'm working to update the branch, but found right now that there's a bug report and a patch upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593653
[02:21] <ari-tczew> Rcart: is it the same as yours?
[02:23] <Rcart> No, looks better
[02:23] <ari-tczew> Rcart: OK then it's fine. You can exchange patch and in Origin tag put link to comment where you found patch
[02:25] <kklimonda> RAOF: assuming that libeven API hasn't changed (which is apparently the case) is it early enough to start the transition for natty? rdepends are http://paste.ubuntu.com/557486/
[02:26] <ari-tczew> how can I delete package from REVU? I found asterisk since asterisk exists in our and Debian archive already.
[02:26]  * ari-tczew has got an idea to clean up REVU after Debian release.
[02:26] <RAOF> kklimonda: If the API hasn't changed then it's simply a rebuild for all rdepends; that list looks nicely leafy.
[02:27] <Rcart> ari-tczew: You mean import the upstream patch, apply it and update the branch, right? Now i got about dep3 tag :)
[02:28] <ari-tczew> Rcart: yes
[02:28] <RAOF> kklimonda: I'd check if everything on that list builds correctly; if so, I'd consider it early enough for the upgrade.
[02:28] <kklimonda> RAOF: yes, that's what I'm planning on doing :)
[02:33] <persia> ari-tczew, The general practice is just to archive anything already in the archives.
[02:41] <Rcart> ari-tczew: Thanks, working on it.
[02:44]  * ari-tczew is off to bed.
[03:35] <kklimonda> directhex: any idea why banshee uses twice as much cpu as rhythmbox?
[03:35] <kklimonda> directhex: while playing music
[06:08] <siretart> bdrung: thanks for noticing. Yes, your suggestion makes sense to me, feel free to adjust the recipie, it belongs to the motumedia team
[06:10] <sagaci_> test
[07:01] <Rcart> Hi!. I'm importing a patch from upstream and i'm gonna include a dep3 tag to the patch. If i include the Bug field, this most point to the launchpad bug report, and the Bug-Debian to, obviously, the debian bug report, right?
[07:02] <broder> Rcart: no, Bug is the upstream bug tracker. Bug-Ubuntu would be for the launchpad bug
[07:02] <broder> err, that is assuming that upstream isn't using launchpad for bugtracking itself...
[07:05] <Rcart> broder: Great, thanks (;
[07:15] <Rcart> broder: Would please give a look to the patch's tag? http://pastebin.com/0WHkwHS3
[07:16] <broder> Rcart: the debian bts isn't upstream for bittornado, is it?
[07:16] <broder> Rcart: also, there should be an empty line separating the dep-3 block and the actual patch
[07:16] <Rcart> broder: No, is not. So the field mos be: Bug-Debian, right?
[07:17] <broder> Rcart: right
[07:17] <broder> Rcart: also, your origin tag isn't very specific - something like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593653#17 would be better (since it references the specific message - i assume that's the specific message)
[07:19] <Rcart> broder: Your're right :)
[07:22] <Rcart> broder: http://pastebin.com/BA1kgDQX
[07:25] <broder> Rcart: that's fine, though it would be nice if you used some of the other optional tags that apply, like author and forwarded (even better is if you actually forward it)
[07:25] <broder> Rcart: but i need to go to bed now. i'm sure anybody else would be happy to assist if you need any further help
[07:26] <Rcart> broder: thanks a lot :)
[08:01] <dholbach> good morning
[08:16] <AnAnt> Hello
[08:16] <AnAnt> why didn't I get this FTBFS http://launchpadlibrarian.net/62702256/buildlog_ubuntu-natty-i386.libgwenhywfar_4.0.3-1_FAILEDTOBUILD.txt.gz on maverick ?
[08:17] <AnAnt> nor on Debian experimental
[08:24] <RAOF> AnAnt: So, it's failing because one of the symbols in went away.  Being C++, that *could* be due to something changing elsewhere in the toolchain.
[08:26] <AnAnt> gcc 4.5 ?
[08:29] <AnAnt> RAOF: so, what should be fixed ?
[08:29] <AnAnt> RAOF: shall I edit the symbols file & reupload , or the fix should actually be somewhere else ?
[08:32] <tumbleweed> AnAnt: it's a destructor, probably not important, I'd guess you can make it optional and avoid a soname bump
[08:35] <AnAnt> tumbleweed: what do you mean by "make it optional" ?
[08:39] <tumbleweed> AnAnt: see dpkg-gensymbols(1). Btw c++filt is very handy for demangling C++ symbols
[08:43] <AnAnt> thanks
[08:44] <AnAnt> tumbleweed: but why did that symbols dissappear on natty, but not on maverick nor experimental ?
[08:44] <kklimonda> hmm, when I prepare a full branch for a merge should I leave release as UNRELEASED or change it?
[08:46] <tumbleweed> AnAnt: different gcc version, I'd assume
[08:47] <tumbleweed> kklimonda: if it's a merge, you might as well change it. If it's a shared packaging branch, UNRELEASED seems sensible, as you don't want a confusing changelog after a rejected review
[08:48] <AnAnt> tumbleweed: how about using the c++ tag ?
[08:49] <kklimonda> tumbleweed: thanks
[08:50] <tumbleweed> AnAnt: if you are the debian maintainer, it's useful, as you can use it instead of mangled symbols in the symbols file. But it doesn't help you here at all
[11:37] <ari-tczew> wrrrrrrrrrrrrrrrrr
[11:37] <ari-tczew> what da f**
[11:37] <ari-tczew> https://launchpad.net/ubuntu/+source/gnucash/1:2.4.0-3
[11:37] <ari-tczew> we have discussion in the night about that
[11:38] <ari-tczew> AnAnt - facepalm!!! if you read this
[11:38] <ari-tczew> this is gigantic transition
[11:42] <ari-tczew> he uploaded packages from experimental without testing before - https://launchpad.net/ubuntu/+source/libgwenhywfar/+changelog
[11:42] <ari-tczew> shameful
[11:42] <ari-tczew> he should lost his upload access
[11:45] <Laney> maybe he wants to handle the transition
[11:49] <Rhonda> !language | ari-tczew
[11:50] <geser> ari-tczew: where did the discussion happen? I see only a discussion about the symbol issue in my scrollback for this channel
[11:50] <ari-tczew> Laney: looking on his activities, I dount
[11:50] <ari-tczew> doubt*
[11:51] <jpds> Oh well, people should use homebank anyway.
[11:52] <ari-tczew> geser: http://paste.ubuntu.com/557610/
[11:52] <ari-tczew> sync gnucash requires sync 2 B-D from experimental and then do transitions. it's clear to understand in above log.
[11:55] <kklimonda> argh, 4 packages ftbfs with libevent2, one of them being developed by the author of libevent himself..
[11:55] <kklimonda> good morning
[11:55] <ari-tczew> hello kklimonda
[11:55] <geser> ari-tczew: so AnAnt wasn't involved in this discussion but missed reading the bug about the sync before using syncpackage?
[11:56] <ari-tczew> geser: yes, he didn't read sync request for gnucash - again, shameful
[11:56] <Rhonda> It looks like there might be a rush of new stuff into Debian testing in march/april going on. I fear that's too late for natty, is it?
[11:56] <ari-tczew> I'm writing e-mail to DMB - Cc to TB since there is only bdrung in DMB
[11:57] <kklimonda> Rhonda: yeah, the feature freeze is at the end of february
[11:57] <ari-tczew> Rhonda: as clarified in log, we are after DIF and that big transitions are too hard to do
[11:58] <Rhonda> kklimonda: hmm, that might enable at least a bit of flow
[11:58] <soren> jpds: Some of us have *actual* accounting to do, you know :)
[11:58] <jpds> soren: Yeah; me too.
[11:58] <Rhonda> Ah, reminds me that I should do a syncrequest for pgadmin3 again, from experimental :)
[11:59] <Rhonda> ari-tczew: Depends on point of view and what one is willing to invest. But we have been through the willingness of investment before, so …
[12:00] <soren> jpds: No support for currencies (let alone multiple currencies), it doesn't seem to even have the concept of expense and income accounts..
[12:01] <Rhonda> So I guess after I finished the job for the squeeze release I'll put special attention in good sync candidates.
[12:01] <soren> jpds: Does it even do double-entry book keeping?
[12:03] <ari-tczew> Rhonda: 1) Didn't check bug before use syncpackage.   2) Didn't test build before uploading - twice!   3) Guess that didn't consider about transitions needed.
[12:05] <geser> ari-tczew: do you know how many packages are involved in this transition?
[12:05] <Rhonda> ari-tczew: I can understand that. But your tone isn't really helpful nor in accordance with CoC, there's no need to swear, even if *ed out.
[12:06] <ari-tczew> geser: I checked in the night - more than 10 IIRC.
[12:06] <chrisccoulson_> how do you know he didn't consider the transition needed? it's not that many packages....
[12:07] <chrisccoulson_> and not reading a comment on a bug against another package is hardly "shameful", as you put it
[12:07] <chrisccoulson_> i think you're over-reacting a bit
[12:07] <ari-tczew> chrisccoulson_: well, I guess as he didn't test build and didn't check difference between packages synced from experimental.
[12:07] <ari-tczew> even if it's sync, developer should check debdiff between dscs
[12:07] <bdrung> ari-tczew: how do you know that he didn't do a build test? sometimes a package builds locally, but fails in the archive.
[12:08] <ari-tczew> bdrung: built not locally
[12:08] <ari-tczew> because I was checking sync request
[12:09] <bdrung> ari-tczew: i assumes it two times that someone didn't build the package before uploading, but in both cases they did and i worked for them for different reasons.
[12:09] <bdrung> ari-tczew: that's why i prefer to ask the people before judging them.
[12:10] <chrisccoulson_> indeed :-)
[12:10] <bdrung> ari-tczew: the old rule of presumption of innocence
[12:11] <ari-tczew> bdrung: I'm 90% sure that he didn't test build and he will tell you that he did test build, because won't admit to the error. naivete!
[12:13] <bdrung> ari-tczew: did he lied before or why are you sure that he will lie?
[12:16] <dholbach> ari-tczew, I think before you start complaining about somebody, you should take the time to get in touch with them and in a very calm way ask what their actual plan was
[12:18] <dholbach> I agree with bdrung that it's a good idea to first assume some kind of misunderstanding or maybe hear more about the motives/plan behind some move
[12:18] <tumbleweed> especially if you actually want to resolve the situation rather than getting everyone's backs up
[12:19] <dholbach> ari-tczew, I'm a bit concerned that your first reaction is to "report the person to the TB/DMB/whoever" before having talked to them
[12:23] <ari-tczew> wait, 10 minutes
[12:23] <ari-tczew> I''ll have interesting log
[12:27] <dholbach> ari-tczew, this is not about proving that you were right right from the start
[12:28] <dholbach> I'm talking about calming down, assuming some kind of misunderstanding in the interest of keeping a good atmosphere AND solving the problem
[12:29] <dholbach> I personally did many mistakes regarding Ubuntu development, but I'm glad they were pointed out to me in a calm way, so I could go and fix them
[12:30] <dholbach> and keeping the atmosphere friendly and encouraging to me is the most important thing here
[12:30] <AnAnt> Hello, is it required that I check for a syncrequest bug before I syncpackage ?
[12:31] <ari-tczew> bingo ;D
[12:31] <bdrung> AnAnt: at least recommended.
[12:32] <dholbach> ari-tczew, give it a break!
[12:32] <ari-tczew> ok folks, transcripts: http://paste.ubuntu.com/557621/
[12:32] <dholbach> it's easy enough to duplicate a bug
[12:32] <ari-tczew> dholbach: you didn't got it, there wasn't duplicate a bug
[12:32] <ari-tczew> just ignore triaging bugs
[12:32] <ari-tczew> he used syncpackage, not archive-admin way
[12:33] <AnAnt> syncpackage shouldn't be used ?
[12:33] <geser> ari-tczew: is this log from a private conversation of you with AnAnt?
[12:33] <ari-tczew> geser: yes, it is
[12:33] <ari-tczew> I know I shoulnd't
[12:33] <ari-tczew> but this is the way to get feedback objective
[12:33] <geser> ari-tczew: did you ask him if it's ok before you published it?
[12:33] <AnAnt> may I know what is wrong ?
[12:33] <ari-tczew> geser: sorry, no
[12:34] <ari-tczew> I'm bad man
[12:34] <Rhonda> ari-tczew: The log shows that you have a rather aggressive style in private queries, too.  And publishing private stuff isn't really helping.
[12:34] <AnAnt> I built libgwenhywfar on maverick, and it built successfully, I didn't imagine that it would FTBFS (for a reason that I still not sure of) on natty
[12:35] <Rhonda> AnAnt: Right, please testbuild in future on the distribution you will upload too
[12:35] <geser> AnAnt: see http://irclogs.ubuntu.com/2011/01/24/%23ubuntu-motu.html#t11:37
[12:35] <bdrung> AnAnt: always build the package which you are going to upload on the target release! change compiler, compiler flags, different libraries lead to build failures.
[12:35] <Rhonda> AnAnt: cowbuilder or pbuild will help you, giving you chroots for that so you don't have to have a system with each distribution next to each other.
[12:35] <AnAnt> what is "facepalm"
[12:36] <Rhonda> AnAnt: http://deb.at/Ifacepalm
[12:36] <ari-tczew> google it
[12:36] <dholbach> AnAnt, it's safe to ignore it
[12:36] <Rhonda> AnAnt: Feel free to ignore that
[12:36] <bdrung> Rhonda, AnAnt: or pbuilder-dist ;)
[12:37] <AnAnt> ok, I did a mistake, that I later fixed
[12:37] <ari-tczew> how can build package for natty on maverick?
[12:37] <AnAnt> but I have the impression, that there is something worse than an FTBFS going on
[12:37] <ari-tczew> it's illogical
[12:38] <bdrung> AnAnt: yes, a started transition.
[12:38] <ari-tczew> you uploaded package with FTBFS - better and preffered way is add patch on package from experimental and upload fixed package
[12:38] <AnAnt> bdrung: 5 packages ?
[12:38] <AnAnt> ari-tczew: why fix it on experimental, if it builds fine there, we don't even know for sure what caused the FTBFS, that was just a workaround !
[12:39] <dholbach> ari-tczew, can you try to calm down? I think AnAnt is fully aware of the mistake now and in addition to that there's still quite a bit of time to fix it - it's not like we're 5 minutes before natty release
[12:39] <ari-tczew> I was overreacted with quantity of transition, yes, sorry. That was not gigantic. But other ways have been neglected.
[12:39] <AnAnt> bdrung: transitions aren't allowed before feature freeze ?
[12:39] <kklimonda> what's the point of this discussion? if it doesn't build, and we can't afford the transition, just downgrade it. It would already be done.
[12:39] <AnAnt> ari-tczew: what other ways ?
[12:39] <kklimonda> really, if we start calling technical board when people make mistakes then no one is going to do any work harder than simple syncs and merges
[12:40] <Rhonda> kklimonda: From what I understood the FTBFS is already fixed.
[12:40] <kklimonda> because something always may break
[12:40] <kklimonda> I'm preparing a migration of libevent2 atm, over 30 packages to rebuild, 8 to change.
[12:40] <kklimonda> should I be scared that someone will yell at me if something breaks?
[12:40] <ari-tczew> AnAnt: no, it didn't build fine on natty. I was checking it some hours ago on pbuilder-NATTY, not maverick.
[12:41] <bdrung> AnAnt: they are allowed, but ari-tczew claimed that you haven't checked that a transition is required for your upload.
[12:42] <ari-tczew> and didn't check existing bug!
[12:42] <AnAnt> I did
[12:42] <ari-tczew> lie
[12:42] <AnAnt> no, I didn't check a bug
[12:42] <dholbach> ari-tczew, calm down
[12:42] <ari-tczew> busted ^^
[12:42] <AnAnt> I checked the transitions
[12:42] <AnAnt> what is this ?
[12:42] <ari-tczew> nevermind, continue
[13:01] <ari-tczew> AnAnt and all: apologies, my reaction was bad. I have not bad intentions. Just making sure for technical quality.
[13:54] <kunal> hello
[13:54] <kunal> If we are reuploading a changed package (after receiving reviews), we need to change version and upload without source code?
[13:55] <kunal> or same version and use -f option?
[13:57] <ari-tczew> kunal: check patch system 0
[13:58] <ari-tczew> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[13:58] <kunal> ari-tczew: thanks
[13:58] <ari-tczew> You're welcome.
[14:01] <kunal> ari-tczew: is this also applicable for uploading on revu?
[14:02] <ari-tczew> kunal: Yes. Do you want to upload a new package?
[14:02] <kunal> ari-tczew: i already have a package there, i want to integrate review changes
[14:03] <ari-tczew> kunal: aha ok
[14:04] <Laney> kunal: keep the same version
[14:05] <Laney> one version per /Ubuntu archive/ upload
[14:05] <kunal> ok
[14:05] <kunal> and changelog?
[14:05] <ari-tczew> 0ubuntu1
[14:05] <kunal> ok
[15:16] <m4n1sh> a package zeitgeist does not have 0.7 version present in Maverick. So I built it in my PPA. Is the versioning 0.7-0ubuntu1~0ppa1~maverick alright? or it breaks it?
[15:17] <ari-tczew> m4n1sh: 0.7-0ubuntu1~maverick1~ppa1
[15:18] <m4n1sh> ara: I thought that maverick should come later?
[15:18] <m4n1sh> ari-tczew: how is that different?
[15:19] <ari-tczew> m4n1sh: backports have ~maverick1 so you should use ppa as a second
[15:19] <m4n1sh> ari-tczew: i think a few people might be using that package
[15:19] <m4n1sh> so I upload a package with this version
[15:19] <m4n1sh> will it be overridden?
[15:20] <ari-tczew> m4n1sh: what version do you have already in PPA?
[15:20] <m4n1sh>  0.7-0ubuntu1~0ppa1~maverick
[15:20] <ari-tczew> not good
[15:20] <ari-tczew> I must  go away right now, I'm late
[15:21] <m4n1sh> ari-tczew: so i should delete and start? or upload it and it will come as an update?
[16:12] <tsimpson> m4n1sh: 0.7-0ubuntu1~maverick1~ppa1 would be better, as if the package is backported to maverick it would be 0.7-0ubuntu1~maverick1, so the backported version would be considered higher than the PPA version
[16:13] <tsimpson> m4n1sh: however, because you put -0ppa1, 0.7-0ubuntu1~maverick1 would still be higher than the PPA version, so it's not going to cause any trouble
[16:19] <micahg> bdrung: is there an option to not upload the .orig.tar.foo with backportpackage? ( I looked at the man page and didn't see one)
[16:39] <Laney> what shall I do with the versioning of a package that was previously removed?
[16:39] <Laney> Only consider the version that was in a release?
[16:39] <Laney> s/removed\?/removed, and I want to bring back?/
[16:43] <Laney> I'll just upload as if it were the next Ubuntu upload normally, that way there shouldn't be any problems.
[16:46] <bdrung> micahg: no. bug #691897
[16:50] <Laney> haskell rebuilds: good for ones karma
[17:00] <m4n1sh> tsimpson: thanks a lot :)
[17:25] <ari-tczew> how can I fix this FTBFS? http://paste.ubuntu.com/557741/
[17:25] <ari-tczew> udienz: you know? ^^
[17:26] <udienz> ari-tczew, adding -lQtCore
[17:27] <ari-tczew> udienz: @QT_LIBS@ is not enough?
[17:28] <udienz> ari-tczew, i guess enough. i look at nvclock maybe QT_LIBS should added after LIBS
[17:29] <udienz> in nvclock_qt:: section
[17:32] <ari-tczew> udienz: now I'm working on nvclock from Debian svn
[17:34] <udienz> ari-tczew: great!  and patch from doko will usable and not useless anymore
[19:27] <paultag> debfx: thanks for the patch against fluxbox, btw
[19:27] <paultag> debfx: don't think I've messaged you directly
[19:28] <paultag> debfx: we fixed it by correcting the underlying issue, but I'd not seen the ftbfs
[19:28] <debfx> paultag: you're welcome :)
[19:31] <paultag> and now, off to uni -- ciao!
[19:31] <debfx> paultag: feel free to ping me once a new version is in debian so I can sync it to ubuntu
[19:32] <paultag> debfx: will do, it's going to be in about two weeks, I got upstream to do a 1.1.3 release ( first release in 3 years! ), and it squashes most of our bugs :)
[19:32] <paultag> debfx: upstream and myself are killing off the last issues before doing 1.1.3, should be nice and stable
[19:46] <RainCT> bdmurray: So python-espeak is an important package?
[19:48] <bdmurray> RainCT: can you remind me of the bug number?
[19:54] <RainCT> bdmurray: bug #580781
[20:00] <bdmurray> since the "upstream" task was high it seemed reasonable to me that the ubuntu one would be too
[20:02] <RainCT> bdmurray: Isn't "A bug that has a severe impact on a non-core application." -> Medium? Anyway, I'm not worried about it, just wondering whether I'd missed something about python-espeak being used (i'm upstream) :P
[20:04] <broder> bdmurray: ubuntu bug priorities are evaluated in the context of ubuntu as a whole, which will almost always deflate the priority relative to how upstream views a bug
[20:06] <bdmurray> Okay I've set it to Medium.
[21:24] <micahg> bdrung: would it be hard to get a flag to not include the orig.tar.foo instead of it being dynamic
[21:24] <bdrung> micahg: i would prefer to have it autodetecting the need of the orig file
[21:25] <micahg> bdrung: that would require querying LP for the status of the package in the archive it'll be uploaded to
[21:26] <bdrung> micahg: yes
[22:59] <bdrung> tumbleweed: bug #707187
[23:41] <bdrung> ari-tczew: please unsubscribe ubuntu-sponsor if you sponsor an upload


[15:24] <OvenWerks> Eickmeyer: I have jack detection working nicely with no extra threading of GUI delay.
[15:26] <OvenWerks> Eickmeyer: I am working on adding backends (firewire and dummy) but could really do much better with a firewire device to play with. I think no one has a device we can test with for example.
[15:28] <OvenWerks> with the backend switch, if the driver is not alsa, I pretty much have to set device to default (this assumes anyone has only one FW device hooked up) and the usb master has to be disabled as well. There are some other things that have to change such as the extra devices have to include whatever just was the alsa jack master. This may be a bigger change than I thought :P
[15:30] <OvenWerks> The other problem is that in order for the FW backend to even work, kernel modules need to be changed. That is the user has to do so system work to even get that far.
[15:30] <OvenWerks> The alsa fw module needs to be removed/blacklisted and the fw modules need to be loaded at boot too.
[15:32] <OvenWerks> I am wondering if we should be worrying about backends at all. FW is for most purposes legacy at best while still being supported by alsa these days.
[15:35] <OvenWerks> However, the few people who do use them have paid a significant amount for them (likewise for my delta66) and would like to keep using them till they croak. The alsa fw experience is not always great, mostly because the code from the FW project was ported into the alsa code without having the various boxes available for testing. So people still want to use the old drivers :P
[15:38] <OvenWerks> So backend support will be rudimentry at best. Mostly an I hope it works solution. AVB may help me get it better, I don't know.
[15:44] <OvenWerks> After more thought... I think I am trying to do the same thing in too many places. I think I will break the device list stuff out of init into it's own call so it can be called any time something changes in that regard. Those times are: at init. if the driver changes, if the master device changes, if the default output changes, if other devices are connected or disconnected.
[15:45] <OvenWerks> I am working on the GUI first... I still have the daemon to do after that.
[15:47] <OvenWerks> Oh, one more thing I don't know how to do (maybe cadence code will help?) is to check if the fw drivers are even there before allowing fw to be selected as backend
[17:09]  * Eickmeyer wakes up and reads the backlock
[17:09] <Eickmeyer> *lgo
[17:09] <Eickmeyer> *log
[17:09]  * Eickmeyer gets coffee
[17:10] <Eickmeyer> OvenWerks: Is there a specific config file we can make and throw into -default-settings?
[17:10] <Eickmeyer> kernel module blacklisting is pretty easy from that perspective.
[21:37] <OvenWerks> Ya blacklisting easy enough, but should we? My thought is that I hope for most people the alsa fw mod just works. The problem is that when it does just work, we don't hear about it. We only hear about the ones that don't.
[21:46] <Eickmeyer> Then perhaps some documentation might be in order.
[22:05] <Eickmeyer> OvenWerks: Do you think that's worth something in the release notes?
[23:21] <OvenWerks> Not for 19.04 I think. To be honest do any of us know enough to to make a note that is worth while?
[23:24] <Eickmeyer> OvenWerks: Probably not. If it's for legacy hardware, I imagine they would find a way to make it work. If they do, then they just need to blacklist the fw modules themselves.
[23:25] <OvenWerks> fw has never been plug and play I think.
[23:25] <OvenWerks> It has always been a tinker's interface.
[23:26] <OvenWerks> on the other hand, to get really good performance from USB interfaces takes some work too.
[23:27] <Eickmeyer> Also, fw is dead anyhow, considering USB has far surpassed it. Despite Apple's best efforts, they eventually caved too.
[23:28] <Eickmeyer> USB takes time, but the key is with the 1ms multiple.
[23:28] <Eickmeyer> aka 3 buffers per period.
[23:28] <OvenWerks> I think AVB/aes67 will be the same
[23:28] <Eickmeyer> So then, we just need to pour our efforts into USB & AVB/AES67.


[16:52] <belkinsa> Reminder, your Checkin-in with the CC is in less than 10 minutes!
[17:01] <belkinsa> Your Check-In Meeting in #ubuntu-meeting, started but your team is in 30 minutes after the Doc Team's.
[17:30] <belkinsa> It's 17:30 UTC, and it's time for your check-in in #ubuntu-meeting.
[17:45] <flocculant> it's 17:44 and docs still going seemingly
[17:45] <belkinsa> Yes, they seem to have lots to say.
[17:45] <belkinsa> I would suggest e-mail the CC your report since there is no time.
[17:46] <flocculant> no thanks - get Nick to if he feels the urge
[17:46] <belkinsa> Alright.
[17:47] <flocculant> not sure there was much or many or more than me from QA to talk from a community perspective
[17:47] <flocculant> but I'd think that if 17:30 is the time it's the CC's job to make it available
[17:47] <flocculant> well - actually I know it is
[17:48] <flocculant> balloons: ^^
[17:49] <flocculant> mhall119 belkinsa: not very good meeting running perhaps
[17:50] <belkinsa> I tired to stop it for the QA team but no one spoke up/
[17:50] <wxl> what happened?
[17:50] <wxl> i just got into the office
[17:51] <flocculant> we got phillibustered by docs going on about how no-one does anything
[17:51] <belkinsa> Your team's check-in meeting with CC is going on but the Doc Team is hoarding the time.
[17:51] <wxl> oh jeez
[17:51] <wxl> wasn't the cc check in supposed to happen like an hour ago/
[17:52] <belkinsa> No, it's still going, 7 minutes left
[17:52] <flocculant> too many mails to the list with different time - not sure why we got something in Eastern time
[17:52] <flocculant> what the hell is that?
[17:53] <flocculant> not that impressed tbh
[17:56] <flocculant> even less so now
[18:36] <balloons> o/ flocculant
[18:41] <flocculant> hi balloons
[19:08] <flocculant> balloons: cc'd you to a mail to Mike
[19:42] <balloons> flocculant, so what do you propose we should do about the ubiquity + AP test situation?
[19:42] <balloons> it seems the changes to ubiquity keeps ensuring they fail
[19:44] <flocculant> well if it keeps failing not much anyone can do
[19:45] <flocculant> I'm glad I made that real basic testcase - at least I can put people on that - does the image boot?
[19:45] <flocculant> just the normal ubuntu thing going on - less than stellar communication
[19:46] <flocculant> I'll just move on and forget about it this cycle
[19:52] <balloons> what are you specifically hoping to test?
[19:53] <flocculant> about all I ever expected of the autotest - that the daily booted
[19:54] <flocculant> but I'll get people to do that
[19:54] <flocculant> just needed to know where *we* stood
[19:54] <flocculant> might be good to let the flavours know this died for this cycle
[19:55] <balloons> interesting.. You only want to know if the desktop loads?
[19:55] <flocculant> well - I was never hopeful of the test doing more - it always missed anything people might see in vb
[19:56] <flocculant> nvm now
[19:56] <balloons> well, I say that because we don't need autopilot for that at all
[19:56] <flocculant> balloons: it's too late in the cycle for me to start fiddling about here
[19:56] <balloons> just because we can't get autopilot to run, doesn't mean we couldn't do a simple test to make sure the machine boots
[19:57] <balloons> basically, that should be trivial to do
[19:57] <flocculant> I'd rather just send a mail to my testers - I have the testcase set up already
[20:38] <dkessel> balloons: how would one do such a test?
[20:39] <balloons> hey dkessel. we can't tell flocculant, but I gutted one of the AP tests to simply stop after the first assert. Just make sure the installer loads is all
[20:40] <dkessel> How would that work with the normal ISO without installing first? Or would it install through something else but ubiquity?
[20:40] <balloons> dkessel, fixing the other tests would be lovely as well of course, but just ensuring it boots works well enough
[20:40] <balloons> dkessel, it loads an image and boots to the installer and makes sure the installer starts fine
[20:41] <dkessel> Oh OK. So no installed system.
[20:41] <balloons> right, no installed system
[20:41] <balloons> the tests fail at some point during the install, but if we care only about it booting ok, that's fine
[20:41] <balloons> it should be a very resiliant test
[20:42] <dkessel> I say put up the Jenkins job for that :)
[20:43]  * balloons is testing to make sure it works now
[20:43] <dkessel> But better don't tell flocculant :D
[20:43] <balloons> yes
[20:48] <balloons> we can also take on any shell scripts and just run those
[22:22] <flocculant> definitely don't tell flocculant
[22:48] <alexbh> Hi... a short question.... how can I know the difference between 20160301 and 20160303? where is it documented?
[22:49] <wxl> alexbh: do you mean how can you tell the difference between the images, or what the changes between the two are?
[22:51] <alexbh> i mean the changes... i want to test again but not sure it is the same image just renamed
[22:51] <wxl> yeah the best you can do is check the package lists against one another
[22:52] <wxl> alexbh: this is on ubuntu or which image?
[22:53] <flocculant> alexbh: pretty sure that if *you've* not got some data from the first to check the new one against - then changes are lost - or extremely hard to work out
[22:53] <alexbh> i did ubuntu, ubuntu-gnome and lubuntu... but it must be the same procedure, right?
[22:53] <wxl> yeah
[22:53] <flocculant> seem to remember this coming up in -release
[22:54] <wxl> so basically you want to go to the cdimage.ubuntu.com page for the image
[22:54] <wxl> and then check the manifests against one another
[22:54] <wxl> e.g. http://cdimage.ubuntu.com/ubuntu/daily-live/20160302/xenial-desktop-amd64.manifest
[22:54] <alexbh> ahh ok... perfect..thanks
[22:54] <wxl> versus http://cdimage.ubuntu.com/ubuntu/daily-live/20160303/xenial-desktop-amd64.manifest
[22:54] <flocculant> wxl: oh - they keep them?
[22:54] <wxl> flocculant: well those two are up for sure1
[22:54] <wxl> flocculant: but if you make sure to pull down the manifests when you grab thge image, you can check them over time, too
[22:55] <wxl> unfortunately an md5 doesn't work even with no changes because there are references to the version number (i.e. the date)
[22:55] <flocculant> of course - not sure I'd bother though :)
[22:55]  * wxl shrugs
[22:55] <wxl> me either
[22:55] <wxl> but i tend to be scientific like that. repeatability is key. no assumptions.
[22:55] <wxl> but THEORETICALLY XD
[22:56] <flocculant> ha ha
[22:57] <flocculant> frankly if it didn't work yesterday but does today then \o/
[22:57] <wxl> heh yep
[22:57] <wxl> BUT WHY WHY??????
[22:58] <wxl> in other news they set up the wiki editors to require ubuntu-etherpad membership as a way to deter spam
[22:58] <flocculant> cos there's no such thing as can't of course :p
[22:58] <wxl> hasn't been officially announced but
[22:58] <flocculant> oh that works then
[22:58] <flocculant> another way to stop people contributing
[22:58] <wxl> it's temporary
[22:58] <wxl> and easy to make people editors
[22:58] <flocculant> isn't it always
[22:58] <wxl> it seems they're still taking the media wiki migration as a serious long term solution
[22:58] <wxl> so i'm pleased about that
[22:59] <wxl> and honestly this is better than the current state of things
[22:59] <flocculant> wxl obviously didn't have to wait for so long to get someone into etherpad that they grabbed rights to do so
[23:00] <flocculant> though it is *usually* quick - but generally I would think that if someone has made the effort to edit a wiki and then has to join some thing they're likely to just wander off
[23:00] <flocculant> I would
[23:01] <wxl> probably
[23:01] <flocculant> and suddenly IS care about spam?
[23:01] <wxl> but at this point the wiki is unusable for ANYONE
[23:05] <flocculant> balloons: so this thing that you can't tell me - will it boot an image - make it try desktop and then check the desktop is there somehow?
[23:05] <flocculant> cos I've not sent the mail yet :p
[23:06] <alexbh> and.. which package is supposed to fix this? https://bugs.launchpad.net/ubuntu/+bug/1551778 I see ubuntu-minimal and ubuntu-standardwere updated but not sure if itt fixes the issue
[23:07] <flocculant> alexbh: how have you built the usb or cd?
[23:07] <alexbh> usb
[23:07] <flocculant> yes
[23:07] <flocculant> but with what tool?
[23:07] <alexbh> ahh.. in ubuntu with the usb creator thingy
[23:07] <flocculant> right - known issue
[23:08] <flocculant> should know the bug number of by heart now ...
[23:08] <alexbh> sorry... what dod you mean?
[23:09] <flocculant> alexbh: it's not new - it's an issue we know about :)
[23:09] <alexbh> ok.. so should I use another tool? because for the stable images it is working
[23:09] <flocculant> alexbh: what are you creating the usb install on?
[23:10] <alexbh> lubuntu 14.04
[23:10] <flocculant> iirc unetbootin worked way back then still
[23:11] <wxl> i just use dd. it never fails.
[23:11] <wxl> mkusb is pretty cool, too.
[23:11] <flocculant> wxl: yea - but because I use dd rarely I never ever tell people how to :p
[23:12] <wxl> flocculant: that's the beauty of mkusb. it's dd under the hood.
[23:12] <flocculant> and mkusb is good as a tool - but last time I looked it was way back in 1999 :D
[23:12] <balloons> flocculant, yep, boots to live desktop, starts installer and just make sure you can interact with it
[23:12] <wxl> yeeeeeeeeeeeeah it's changed a bit :)
[23:12] <flocculant> and sudodus know's me well enough to know I am not being anything but nice :D
[23:14] <flocculant> balloons: \o/
[23:37] <alexbh> the bug is this one, right? https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1360823
[23:45] <flocculant> alexbh: I do apologise - I wandered off ...
[23:45] <flocculant> the bug is the main one
[23:45] <flocculant> 1325801
[23:47] <flocculant> alexbh: so you should be able to boot from that usb - when it gets to a prompt - try live and enter


[00:40] <tartar> I have a pair of conf files, one for a service SERVICE.conf and another for a task blocking its dependants from starting earlier, SERVICE-block-dependants.conf.
[00:41] <tartar> How do I block the pre-start of SERVICE.conf until mounted MOUNTPOINT=/ ?
[00:43] <tartar> Currently I wait for a writeable directory the service needs in its pre-start and absence of *fsck* processes.
[00:46] <tartar> This worked around the scenario when the dependants start early in /sbin/init, running "start SERVICE".  At that point / still mounts in memory and an mountall runs fsck for the root disk partition.  That fsck process may take a minute or more on exceeding the maximum count.
[00:47] <tartar>     while ! test -w /var || killall -0 --regexp fsck ; do
[00:47] <tartar>          sleep 1
[00:47] <tartar>      done > /dev/null 2>&1
[00:48] <tartar> But this still suffers from a timing window between the exit of fsck and the mount of /.
[00:50] <tartar> I would rather depend on "mounted MOUNTPOINT=/", but I find difficult to inject this hook into the pair.
[00:52] <tartar> It does not matter how long fsck runs, the timing window would present the same probability for SERVICE to use the fake /var.
[00:53] <tartar> If that happens, mountall's mounting / against the real disk partition causes the loss of file entries the service created in the fake /var.
[01:04] <tartar> I could use the output of "df /var" to tell if /var belongs in a disk, but this does not look as nice as "mounted MOUNTPOINT=/".
[01:07] <tartar> It would be nice if I could use a conjunction "and" against a set of "or" hook events in SERVICE-block-dependants.conf, but I heard this suffered from a bug and I am stuck with Lucid for now.
[01:11] <tartar> Using "and" in SERVICE-block-dependants.conf would mix up the existing hook events for SERVICE's dependants with the new hook event for SERVICE's requisite.  This would complicate reasoning for the SERVICE-block-dependants.conf.
[01:15] <tartar>
[01:16] <tartar> To sum up, I need to wait for a hook or pass if the hook already went by.
[01:16] <tartar> Can initctl do that?
[01:24] <tartar> Alternatively, I would love to "initctl emit wait-for-mountall MOUNTPOINT=/" if mountall could receive upstart events.
[01:33] <tartar> I guess some mountall-watch.conf could "start on wait-for-mountall MOUNTPOINT=/ and mounted MOUNTPOINT=/"?  Will Lucid's upstart wait for 2 hook events in any succession before returning control to the above "initctl emit"?
[01:35] <tartar> I do not need MOUNTPOINT=/ in wait-for-mountall.
[01:41] <tartar> To shorten that, I do not need to send a hook, I could just "start on starting SERVICE and mounted MOUNTPOINT=/" in some root-block-SERVICE.conf.
[05:07] <keshav89> Hello everyone
[05:07] <keshav89> I am a newbee in upstart
[05:07] <keshav89> Just got to know about upstart
[05:07] <keshav89> as I was searching for a process management tool
[05:08] <keshav89> Requirement was running my flask app forever
[05:08] <keshav89> Basically I have ubuntu VM to which I ssh and run my "python flaskapp.py" - which starts a dev server
[05:09] <keshav89> but if ssh connection breaks that server comes down
[05:09] <keshav89> came to know about gunicorn and then upstart
[05:09] <keshav89> read the doc of upstart a bit
[05:10] <keshav89> Here is what I understand:
[05:10] <keshav89> 1. I need to write one simple myflask.conf
[05:10] <keshav89> 2. Plcae it under /etc/init/
[05:10] <keshav89> *Place
[05:12] <keshav89> 3. in that script I will write something like : "pre-script chdir <flask_dir> end script exec python flaskapp.py"
[05:12] <keshav89> Am I correct?
[05:12] <keshav89> with script i meant myflask.conf which will be placed under /etc/init/
[05:13] <keshav89> Any help or assistance appreciated
[05:17] <keshav89> oh I should also have this line in the .conf file : "start on startup" right?
[05:31] <keshav89> anybody?
[05:32] <keshav89> :-[
[11:59] <keshav89> I have a small conf file under /etc/init/
[11:59] <keshav89> Which I am trying to run
[11:59] <keshav89> with initctl
[12:00] <keshav89> start on startup
[12:00] <keshav89> pre-start script
[12:00] <keshav89> # Changing directory to flask app
[12:00] <keshav89>    chdir /usr/src/test/ans/
[12:00] <keshav89> end script
[12:00] <keshav89> script
[12:00] <keshav89>    gunicorn -b <IP_ADDRESS>:1234 testflask:app
[12:00] <keshav89>    console output
[12:00] <keshav89> end script
[12:00] <keshav89> Basically I am trying to keep flask server running
[12:01] <keshav89> Am I doing something wrong?
[12:01] <keshav89> I am trying initctl start myflask.conf
[12:16] <keshav89> Anyone?
[12:33] <keshav89> http://paste.ubuntu.com/5598674/
[13:38] <xnox> tartar: http://upstart.ubuntu.com/cookbook/ see "how to block another job"
[13:38] <xnox> you can create a job which will block your main one, until complete. I think that will work for you.
[13:39] <xnox> keshav89: http://upstart.ubuntu.com/cookbook/#chdir stanza?
[17:58] <jamescarr> SpamapS: this is a shot in the dark, but your name came up when I was frantically googling for libmysqlclient-dev help on ubuntu :)
[17:58] <jamescarr> SpamapS: do you know where I might find one of the maintainers on irc? Or at least someone familiar with it?
[18:15] <jamescarr> SpamapS: never mind, I see you're one of them
[19:05] <SpamapS> jamescarr: I'm a maintainer yes. Want to chat in #ubuntu-devel ?
[19:05] <jamescarr> sure
[19:06] <preyalone> I like to start little web servers on boot. I've been using upstart, but often my scripts fail, causing important services like sshd to fail to start. What's a safer way to do this?
[19:08] <jamescarr> preyalone: I've never seen sshd not get started, are you fooling with the maintainer provided upstart scripts?
[19:10] <preyalone> jamescarr: I haven't fooled with anything. I recently upgraded my hardware (I use Gandi VPS hosting), and the sysadmin helping me with the upgrade mentioned that when my upstart scripts fail, it can cause things like sshd to not start up.
[19:10] <SpamapS> preyalone: thats b.s.
[19:11] <jamescarr> yah what SpamapS said
[19:11] <preyalone> Understood.
[19:11] <SpamapS> preyalone: can you share your upstart job that sometimes fail?
[19:11] <jamescarr> just because an upstart script fail doesn't keep others from running
[19:11] <SpamapS> preyalone: I'd bet that you're starting things too early
[19:11] <preyalone> In any case, I've noticed that my upstart scripts DO fail a lot, so when my server restarts, I'll notice that a service isn't running at all. Example: https://github.com/mcandre/node-ios7crypt/blob/master/upstart.conf
[19:11] <SpamapS> jamescarr: well, a failing job could certainly have also somehow cancelled another one. But.. yeah
[19:12] <SpamapS> yep
[19:12] <SpamapS> preyalone: man upstart-events
[19:12] <SpamapS> preyalone: startup is *WAY* too early
[19:12] <SpamapS> preyalone: no network, no disks, nothing
[19:12] <SpamapS> preyalone: its only by a miracle that 'start on startup' ever works.
[19:12] <SpamapS> preyalone: you want 'start on runlevel [2345]'
[19:12] <preyalone> SpamapS: Thanks. :P
[19:13] <SpamapS> preyalone: also, 'shutdown' is not an event. So you want 'stop on runlevel [016]'
[19:13] <SpamapS> man
[19:13] <SpamapS> there are a few examples that use those two events
[19:13] <SpamapS> and they are like *weeds*
[19:13] <SpamapS> kill 1, 5 more pop up
[19:16] <preyalone> Can upstart scripts use hard tabs, soft, or what?
[19:18] <SpamapS> preyalone: doesn't matter
[19:18] <SpamapS> preyalone: they are not whitespace sensitive
[19:18] <preyalone> Is that standard for .conf files, or just upstart .conf files?
[19:23] <SpamapS> upstart
[19:23] <SpamapS> .conf means nothing
[19:24] <SpamapS> /etc/init/*.conf == upstart
[19:31] <preyalone> SpamapS: Thanks for the info. I'm just thinking about configuring indentation in my text editor.
[20:06] <preyalone> My Rails app works when I start it manually. But when I try to call the same command via upstart, my server doesn't start up. https://github.com/mcandre/doesrailswork/blob/master/upstart.conf
[20:08] <xnox> preyalone: no need to use script, the exec and chdir are top level stanzas just like "start on"
[20:09] <preyalone> xnox: Thanks, but that doesn't alter the behavior.
[20:09] <xnox> there is no command line executable "chdir" so that's where the script fails.
[20:10] <xnox> as the whole script is executed as if it's shell, with set -e
[20:12] <preyalone> "rails server" needs to be executed in a specific current directory. What's the best way to do this in upstart?
[20:19] <preyalone> xnox: I tried moving chdir and exec outside of script, but the problem still exists: the Rails app isn't running after I do "sudo start doesrailswork".


[09:01] <zaytsev> doko: hi, just a short question and specifically, any plans for toolchain test build of gcc 5.2 for precise?
[09:01] <zaytsev> doko: i'm enjoying the gcc 5.1 builds from the toolchain ppa, simply indispensable
[10:06] <doko> zaytsev, sure, but lack of time currently
[10:48] <zaytsev> doko: awesome, many thanks, i'll wait


[15:00] <matsubara> #startmeeting
[15:00] <MootBot> Meeting started at 10:00. The chair is matsubara.
[15:00] <matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
[15:00] <matsubara> [TOPIC] Roll Call
[15:00] <MootBot> New Topic:  Roll Call
[15:00] <sinzui> me
[15:00] <matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
[15:00] <bigjools> me
[15:00] <herb> me
[15:00] <stub> me
[15:00] <henninge> meeee
[15:00] <Ursinha> me
[15:01] <matsubara> rockstar: hi
[15:01] <rockstar> me
[15:01] <matsubara> intellectronica: hi
[15:01] <intellectronica> me
[15:02] <matsubara> all right. flacoste can join later
[15:02] <matsubara> [TOPIC] Agenda
[15:02] <MootBot> New Topic:  Agenda
[15:02] <matsubara>  * Actions from last meeting
[15:02] <matsubara>  * Oops report & Critical Bugs
[15:02] <matsubara>  * Operations report (mthaddon/herb/spm)
[15:02] <matsubara>  * DBA report (stub)
[15:02] <matsubara> [TOPIC] * Actions from last meeting
[15:02] <MootBot> New Topic:  * Actions from last meeting
[15:02] <matsubara>   * matsubara to chase rockstar about OOPS-1152XMLP1
[15:02] <matsubara>     * talked to mwhudson about this one and filed bug 338535
[15:02] <matsubara>   * Ursinha to talk to rockstar about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1159EA69
[15:02] <matsubara>   * Ursinha to file a bug about OOPS-1160ED105 and assign to intellectronica
[15:02] <matsubara>     * done: 337811
[15:02] <matsubara>   * matsubara to chase the code guys about bug 337942
[15:02] <matsubara>     * talked to thumper about this one. Importance was lowered and explained in the bug report.
[15:03] <Ursinha> hey rockstar :)
[15:03] <Ursinha> can you take a look on that oops?
[15:03] <rockstar> Hi Ursinha
[15:03] <rockstar> Ursinha, that looks like a Soyuz oops.
[15:04] <matsubara> soyuz?
[15:04] <Ursinha> rockstar: huh?
[15:04] <rockstar> NoSuchDistroSeries: No such distribution series: 'totem'.
[15:04] <bigjools> it looks like source package branches?
[15:05] <Ursinha> bigjools: do you agree with rockstar?
[15:05] <rockstar> Oh, huh.  Looking at the traceback, it's doing something with the XML-RPC server.
[15:05] <bigjools> Ursinha: no
[15:05] <Ursinha> rockstar: :)
[15:05] <rockstar> So that might be a code thing after all...
[15:06] <rockstar> I would say that's a relatively low priority, since source package branches aren't completely working.  I'll talk to jml about it.
[15:06] <Ursinha> rockstar: thanks. Want me to file a bug?
[15:06] <matsubara> [action] Ursinha to file a bug about OOPS-1159EA69
[15:06] <rockstar> Ursinha, yes please.
[15:06] <MootBot> ACTION received:  Ursinha to file a bug about OOPS-1159EA69
[15:06] <Ursinha> thanks rockstar
[15:07] <matsubara> all right. thanks rockstar, Ursinha
[15:07] <matsubara> [TOPIC] * Oops report & Critical Bugs
[15:07] <MootBot> New Topic:  * Oops report & Critical Bugs
[15:08] <Ursinha> one issue for bugs: intellectronica, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1166F631
[15:09]  * Ursinha wonders if the internet is off again
[15:09] <intellectronica> haven't seen anything like this before. will investigate
[15:09] <intellectronica> Ursinha: you gonna file a bug, or should i?
[15:10] <Ursinha> thanks intellectronica
[15:10] <Ursinha> intellectronica: I will
[15:10] <matsubara> [action] Ursinha to file a bug about OOPS-1166F631 and assign to intellectronica
[15:10] <MootBot> ACTION received:  Ursinha to file a bug about OOPS-1166F631 and assign to intellectronica
[15:10] <intellectronica> oh, it's some problem working with data from apport
[15:11] <rockstar> Someone needs to teach ubottu about the new OOPS url.
[15:11] <matsubara> intellectronica: looks like apport data isn't sending the correct headers
[15:11] <intellectronica> yes
[15:11] <matsubara> all right. thanks intellectronica
[15:12] <matsubara> we have 1 critical bug which is in progress already.
[15:12] <matsubara> bug 341251
[15:12] <intellectronica> or that our parsing of the headers is incorrect
[15:12] <Ursinha> right, that's all from me
[15:12] <matsubara> ok. thanks Ursinha
[15:12] <matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
[15:12] <MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
[15:12] <herb> 2009-03-10 - Cherry picked r7907 to the scripts server to fix bug #300634.
[15:12] <herb> Bug #156453 and bug #118625 continue to be a daily problem.
[15:12] <herb> Bug #260171 is still causing a problem every few days.
[15:13] <herb> There are currently 3 pending cherry picks, two of which need approval.
[15:13] <sinzui> matsubara: bugs 341085, 341117 landed, but misses the edge update
[15:13] <intellectronica> whoops
[15:14] <Ursinha> ouch
[15:14] <intellectronica> ubottu should really start using the api
[15:14]  * sinzui thinks those bugs are private
[15:14] <matsubara> sinzui: thanks for fixing it so quickly.
[15:14] <herb> at least one of them is.
[15:14] <matsubara> sinzui: are we going to need a cp for those?
[15:15] <sinzui> matsubara: they could be, I'm inclined to push for it since the next release on on April 1
[15:15] <matsubara> [action] sinzui to request CP for bugs 341085 and 341117
[15:15] <MootBot> ACTION received:  sinzui to request CP for bugs 341085 and 341117
[15:16] <matsubara> hey rockstar, any news about the loggerhead work that would make the LOSAs happier?
[15:16] <rockstar> matsubara, well, nothing concrete.
[15:16] <matsubara> :-(
[15:17] <rockstar> Every time we commit something, we *think* it'll fix it, but it never completely fixes it.
[15:17] <rockstar> We are planning on chasing down the right people at PyCon to give us some definitive answers.
[15:18] <rockstar> Profiling/debugging an application like this isn't trivial, so we're kinda doing our best with the voodoo we have.
[15:18] <matsubara> rockstar: last meeting, I think stub suggested contracting someone to look at those problems. did you consider that?
[15:19] <rockstar> matsubara, probably not.
[15:20] <matsubara> rockstar: bring it up with the Code team. see what they think about it
[15:20] <matsubara> anyway, let's move on.
[15:20] <matsubara> thanks rockstar and herb
[15:20] <matsubara> [TOPIC] * DBA report (stub)
[15:20] <MootBot> New Topic:  * DBA report (stub)
[15:20] <herb> thanks matsubara, rockstar
[15:20] <stub> Database maintenance tools are being updated to work with multiple slaves, including bringing them up and dropping them. The new slave should be live early next week.
[15:20] <stub> Nothing else to report.
[15:21] <matsubara> I forgot one thing, herb
[15:21] <matsubara> herb: staging is running in its new hardware now, right?
[15:21] <herb> the staging db is running on it's new hardware, yes.
[15:22] <herb> s/it's/its/
[15:22] <matsubara> ok, cool!
[15:22] <matsubara> thanks stub, herb
[15:22] <matsubara> anything else before I close?
[15:23] <matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
[15:23] <matsubara> #endmeeting
[15:23] <MootBot> Meeting finished at 10:23.
[15:23] <bigjools> thanks matsubara
[15:24] <intellectronica> thanks matsubara
[15:24] <Ursinha> thanks matsubara
[15:25] <Ursinha> intellectronica: /11
[15:25] <matsubara> you're welcome
[15:25] <Ursinha> intellectronica: sorry, bug 341766
[15:25] <intellectronica> Ursinha: never saw that one before
[15:25] <Ursinha> :)
[15:26] <Ursinha> intellectronica: irssi fail
[15:26] <intellectronica> ah, of course :)
[15:26] <intellectronica> Ursinha: thanks
[15:26] <intellectronica> Ursinha: b.t.w have we seen this oops many times, or just this single instance?
[15:27] <intellectronica> i'm asking so that i can determine the importance
[15:29] <Ursinha> intellectronica: I've seen this one a few times a day
[15:30] <intellectronica> really? wow, that's bad. i wonder if apport changed
[15:30] <intellectronica> maybe it changed it's a jaunty/apport bug?
[15:31] <Ursinha> hmm, worth more checking
[15:33] <Ursinha> intellectronica: I don't think it's a apport change, because I guess there would be a lot more it that was the case, no?
[15:33] <intellectronica> Ursinha: don't know. if it's a very recent change, then maybe not many people have that version
[15:33] <matsubara> Ursinha: https://dev.launchpad.net/LaunchpadBugTags
[15:34] <Ursinha> matsubara: thanks
[15:34] <intellectronica> Ursinha: the malone code we're looking at hasn't changed in a long long time
[15:34] <Ursinha> intellectronica: hmmm, maybe. I'm using jaunty and already "reported" many incidents
[15:34] <Ursinha> didn't hit any problems so far
[15:35] <matsubara> Ursinha, intellectronica: could be some specific error report triggering the error. Are all oopses caused by the same person?
[15:36]  * Ursinha looks
[15:36] <intellectronica> is there now way to get the username from the oops report?
[15:37] <intellectronica> i only see the full name and db id
[15:39] <Ursinha> intellectronica: indeed
[15:39] <Ursinha> intellectronica: I'll open a bug about it and matsubara will check
[15:40] <intellectronica> anyway, given that the user is not member of any team, i would guess that it's probably not the case that he's using a super latest version of apport
[15:40] <Ursinha> intellectronica: I lied, I saw a few occurrences but not daily
[15:40] <Ursinha> intellectronica: do you want to see the oopses?
[15:40] <Ursinha> I'll append them to the bug report
[15:41] <intellectronica> Ursinha: yes, that would be great
[16:31] <Ursinha> intellectronica: I finally managed to convince my internet to edit the bug 341766
[16:31] <Ursinha> I placed there all oopses I could find
[16:31] <Ursinha> this year
[16:31] <intellectronica> Ursinha: thanks muchly!
[16:32] <Ursinha> intellectronica: my pleasure! :)
[16:32] <intellectronica> oh, were there ones from previous years?
[16:32] <intellectronica> so, basically, this isn't a very recent thing?
[16:32] <Ursinha> yes, but very rare
[16:32] <Ursinha> unfortunately not :(
[16:35] <Ursinha> intellectronica: talking about apport, another one, but this is quite frequent: bug 329908
[16:38] <intellectronica> Ursinha: happy days


[00:32] <karlthane> Hello, trying to help test. Downloaded the current daily iso for 19.10, not giving option to install to zfs in installer. Is there something special I have to do. Sorry if this is wrong channel.
[01:01] <valorie> karlthane: try #ubuntu+1
[10:35] <caribou> Hello, I'm preparing an SRU upload of systemd for LP: #1805183. Anybody has something inflight on systemd ?
[14:01] <tomreyn> gnupg2 (as well as gnupg, i.e. v1) in bionic fails to handle keys without user ids, as provided by the (only, as far as i know) key spam safe openpgp server keys.openpgp.org, which most applications now default to.
[14:01] <tomreyn> so it's not currently possible to use a safe keyserver in bionic, from what i can tell.
[14:01] <tomreyn> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930665
[14:13] <TJ-> tomreyn: I find that vulnerabilty useful... as I have multiple IDs if the same email arrives for multiple IDs it gets deleted instantly by procmail
[14:18] <tomreyn> TJ-: well, that's not so useful to me ;)
[14:22] <TJ-> hehehe
[14:22] <TJ-> tomreyn: so is it no longer possible to search by userid to find a key?
[14:23] <TJ-> tomreyn: hmm, is that keyserver not connected to the pool? it doesn't find my key
[14:35] <tomreyn> TJ-: it is not connected to the SKS pool. are you aware of the signature spamming issues?
[14:36] <tomreyn> i just filed bug 1844055 about the above.
[14:38] <TJ-> tomreyn: you mean the email addresses being harvested for spam? Yes, seen it for a long time which is why I have procmail rules to block it
[14:39] <TJ-> tomreyn: hashes the subject and counts for all IDs in the keys
[15:03] <tomreyn> TJ-: no, i don't mean e-mail addresses harvested for spam. i mean the issue known as (variants of) OpenPGP certificate (key signature) flooding / spam. I added more context to the bug report now.
[15:09] <TJ-> tomreyn: ahhh, thanks, so adding lots of signatures to a key as a DoS because clients cannot cope with the quantity?
[15:12] <tomreyn> TJ-: yes, this sums up CVE-2019-13050, mitigation of which got deferred https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-13050.html
[15:15] <TJ-> tomreyn: reading about the unmaintained 'toy' SKS software and the fact 2 key devs of openpgp have known about this for 10 years... I dispair!
[15:15] <TJ-> I despair, too!
[15:25] <tomreyn> yes, it's overall a sad situation. :/
[15:27] <TJ-> the argument 'no-one can understand the code' is a poor one though; that is always possible if sufficient time is applied
[15:37] <tomreyn> i wouldn't personally claim to be able to do so, not now, nor anytime soon. but certainly time, accompanied by other resources, such as knowledge and experience, money, could. the argument resting within this, that infrastructurally important or at least relevant software should be written in a widely understood programming language, accompanied by good documentation. (this said, i'm very grateful to kfiskerstrand and other contributors to
[15:37] <tomreyn> the SKS keyserver code and network over the years.)
[15:38] <tomreyn> s/within this , that/within this is that/
[15:38] <tomreyn> and we should move to -discuss.
[17:49] <karlthane> @valorie Thank You
[17:49] <udevbot> Error: "valorie" is not a valid command.
[17:49] <karlthane> valorie Thank you.
[17:59] <Eickmeyer> cyphermox: Still no movement on bug 184319?
[17:59] <Eickmeyer> Oh, wrong bug...
[18:00] <Eickmeyer> cyphermox: bug 1843196


[23:15] <stephen101> I found a bug which idk whether its software or Intel's microcode.
[23:15] <stephen101> http://paste.ubuntu.com/26158204/
[23:16] <stephen101> This has not specifically been addressed as far as my searches on Ubuntu bugs. But people with same processor as me on different distros have same MCE error.
[23:19] <stephen101> My processor is Intel® Dual-Core Celeron® N3350
[23:19] <stephen101> I have extensively benchmarked my machine without error.
[23:20] <stephen101> windows, Ubuntu, and passmark on boot.
[23:26] <stephen101> Also tried upgrading/downgrading bios and older / newer Intel microcode


[00:09] <mup> Bug #1710308 opened: [2.2] MAAS should throttle bind reloads <MAAS:Triaged> <MAAS 2.2:Triaged> <https://launchpad.net/bugs/1710308>
[00:09] <mup> Bug #1710310 opened: [2.2] DNS service monitoring should issue test queries <MAAS:Triaged> <https://launchpad.net/bugs/1710310>
[04:18] <mup> Bug #1588466 changed: gpg --batch --verify during maas install causes Unhandled Error <cdo-qa> <MAAS:Expired> <simplestreams:Incomplete> <https://launchpad.net/bugs/1588466>
[04:36] <mup> Bug #1588466 opened: gpg --batch --verify during maas install causes Unhandled Error <cdo-qa> <MAAS:Expired> <simplestreams:Incomplete> <https://launchpad.net/bugs/1588466>
[04:42] <mup> Bug #1588466 changed: gpg --batch --verify during maas install causes Unhandled Error <cdo-qa> <MAAS:Expired> <simplestreams:Incomplete> <https://launchpad.net/bugs/1588466>
[06:21] <maasCluster> I've just recently setup MAAS Region controller and cannot get additional MAAS nodes to remain on during boot up... Get a power error each time, and the nodes then turnoff after getting commands from MAAS controller
[06:21] <maasCluster> Can anyone help please
[06:22] <maasCluster> I occasion can get one or two of the nodes to stay on (green on, and ready state)... but then when trying to get the 3rd node on, everything powers off
[12:14] <jcordeiro> is there a known bug that makes my MAAS machine go 100% cpu on idle?
[12:15] <jcordeiro> jesus lutostag ... thats some bad connection you have
[12:19] <jcordeiro> with 8 cpus my load is 14
[12:20] <jcordeiro> the thing using all my cpu is:
[12:20] <jcordeiro>  9332 maas      20   0 1522636 190196  19832 R  42.4  1.2 666:15.00 twistd3
[12:21] <jcordeiro> https://bugs.launchpad.net/maas/+bug/1558314 ...
[12:22] <jcordeiro> https://bugs.launchpad.net/maas/+bug/1705518
[12:24] <jcordeiro> lol, that was fast on lutostag


[10:55] <GunnarHj> happyaron: Please read my latest comment at bug #1481025.
[10:55] <ubot5`> bug 1481025 in language-selector (Ubuntu) "Keyboard shortcut for layout switching works in Unity but not in Gnome-Flashback" [Medium,Fix committed] https://launchpad.net/bugs/1481025
[19:01] <SilverBack> anybody know how to change the gtk3 dropshadow color (for open windows)
[21:27] <TheMuso> Morning folks.