[02:05] <imgbot> [03:30] <imgbot> [03:30] <imgbot> [06:02] <rsalveti> ogra_: mind triggering a new image in a few hours? want to have a new image now that hybris landed
[09:02] <Mirv> adb shell
[09:03] <Mirv> mm
[09:26] <dbarth_> hi trainguards: can i get a silo for line 60 please?
[09:30] <ev> popey: looking now
[09:30] <Mirv> dbarth_: sure
[09:30] <popey> ev: thanks.
[09:31] <Mirv> dbarth_: in a minute.. hangout starting (if anyone else joins:) + spreadsheet broken needs some manual hackery
[09:38] <dbarth_> Mirv: ah, let me know
[09:38] <dbarth_> Mirv: there's also the qtwebkit dep drops i wanted to review with you, with that qquickview FTBS issue in parallel
[09:42] <Mirv> dbarth_: you've bug report in the MP line...
[09:43] <Mirv> dbarth_: and sure, throw MP:s at my direction and I'll check if the dep drops look proper
[09:46] <dbarth_> Mirv: ok, you've got an mp in the line now, sorry
[09:52] <Mirv> dbarth_: ^
[09:54] <dbarth_> thank!
[09:54] <dbarth_> s
[10:20] <ogra_> imgbot, status 138
[10:20] <imgbot> Error: There does not seem to be any build with the number 138
[10:22] <davmor2> john-mcaleely: did you get my message last night about the vivid device tarball?
[10:27] <ev> popey: I've updated the bug. I don't think this is a firewall issue.
[10:39] <popey> ev: thanks
[10:45] <imgbot> [10:45] <imgbot> [10:45] <ogra_> ah, hello
[10:52] <abeato> trainguards, can I have a silo for line 59?
[10:52] <john-mcaleely> davmor2, ah, no I don't think so
[10:55] <john-mcaleely> davmor2, what was the message?
[10:55] <davmor2> john-mcaleely: device tarball for vivid is good :)
[10:56] <john-mcaleely> \o/
[10:56] <john-mcaleely> who's a good person to care if pushing now is good/bad?
[10:56] <davmor2> Mirv: ^
[10:56] <davmor2> ogra_: ^
[10:57] <ogra_> go for it
[10:57] <john-mcaleely> ack
[10:58] <john-mcaleely> pushed!
[10:58] <john-mcaleely> thanks davmor2, ogra_
[11:22] <Mirv> abeato: you already have. like it says on the spreadsheet, for now trust the dashboard not spreadsheet
[11:23] <abeato> Mirv, oh, it is those problems with the spreadsheet mentioned in an e-mail
[11:23] <abeato> Mirv, noted, thanks
[11:25] <Mirv> indeed
[14:03] <Mirv> uh oh, the spreadsheet looks to me to have reset itself to days earlier version
[14:03] <Mirv> in addition to all the other errors recently
[14:05] <Mirv> to be precise, it has resetted itself to Sunday evening
[14:05] <Mirv> I know sil2100 had some sort of backups from where to restore lines
[14:13] <Mirv> robru: ^ if you know anything about spreadsheet backups, could be nice to restore some of today's and yesterday's lines. if not, then we just use the dashbaord as usual to land the disappeared lines.
[14:14] <Mirv> or maybe it restores itself by time, it's giving server error for me all the time as well
[14:17] <robru> Mirv: I can't remember where sil keeps his backups. is he not around today?
[14:20] <Mirv> robru: he might visit for a short while soon, but he's mostly away today
[14:21] <robru> Mirv: my shift doesn't start for a couple hours, I can try copy&pasting from the dashboard back to the spreadsheet but that's painful.
[14:27] <robru> Mirv: I dunno why I'm awake this early, bbl
[14:38] <sil2100> o/
[14:41] <sil2100> Great, my mailbox is spammed full with google spreadsheet errors
[14:48] <jhodapp> sil2100, can you please reconfigure vivid silo 23 for me?
[14:48] <sil2100> jhodapp: sure, will try at least (the spreadsheet is misbehaving a bit)
[14:49] <jhodapp> ok
[14:54] <sil2100> jhodapp: should be good now
[14:55] <jhodapp> sil2100, thanks!
[15:02] <Mirv> sil2100: jibel: keep me posted. Kubuntu would like to land the next KDE frameworks, and since that would delay Qt landing (release pocket migration) significantly I've told them to wait until I know if 5.4.1 can be landed or not
[15:03] <sil2100> Mirv: sure, we're having the meeting right now
[15:03] <Mirv> since 5.4.1 is all built and ready and their landing consists of tens of packages that keep blocking each other until day or two later, and the last bits in the chain are what are related to Qt too
[15:04] <sil2100> Ok
[15:19] <sil2100> Mirv: ok, we have a +1 from pmcgowan and the PT to land 5.4.1 :)
[15:19] <sil2100> Mirv: so whenever you're ready, publish o/
[15:22] <Mirv> sil2100: ok!
[15:25] <Mirv> sil2100: bah, after those few others "ERROR Critical data missing from packagelist." https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/71/console trying to do build..
[15:26] <sil2100> Mirv: I think a watch only build should be enough
[15:26] <Mirv> sil2100: there is a recent build job from Satuday though
[15:26] <Mirv> sil2100: well normal build should do the same, right? since there's nothing to build anyway.
[15:26] <Mirv> anyway, launched watch_only now
[15:26] <Mirv> if I remember correctly it's faster nowadays (thanks robru!)
[15:28] <Mirv> it used to take 40 mins, now it should be somewhat faster at least
[15:30] <sil2100> Yeah ;)
[15:31] <sil2100> jibel, robru, davmor2, rvr, popey: since I'm off sick today, you guys want to have the evening meeting without me or should I remove it from the calendar?
[15:31] <om26er> trainguards I am looking at the spreadsheet and could not find silo an entry for silo-016 of ofono
[15:31] <popey> sil2100: I'm afk all day so won't join
[15:31] <om26er> it does appear on trello
[15:31] <popey> well, at keyboard, in london
[15:31] <davmor2> om26er: the spreadsheet is broken
[15:31] <sil2100> om26er: hm, the spreadsheet had issues so it might have been reverted by google
[15:31] <sil2100> om26er: I'll try to bring it back from backups
[15:32] <sil2100> Give me a moment
[15:32] <rvr> sil2100: So you broke the spreadsheet and now run away, uh? ;)
[15:32] <davmor2> om26er: it's in the topic, trust the dashboard not the spreadsheet
[15:32] <om26er> sil2100, thanks
[15:32] <om26er> davmor2, never used the dashboard :D
[15:32] <sil2100> rvr: no! *coughs* I'm... I'm just so sick... *runs away*
[15:32] <rvr> sil2100: hehe
[15:32] <rvr> Apart from that, no news from my side
[15:32] <rvr> om26er: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=
[15:33] <davmor2> sil2100: do we know what is happening with QT that would be the only think that would need discussing
[15:33] <Mirv> sil2100: it was reverted to Sunday evening, which I noticed 1.5h ago
[15:33] <om26er> rvr, hmm, they don't include link to TestPlan ?
[15:34] <rvr> om26er: That's in the spreadsheet
[15:34] <sil2100> davmor2: it's landing ;) I already told Mirv to release it so he's working on it
[15:34] <davmor2> \o/
[15:34] <rvr> Nice
[15:34] <rvr> davmor2: Should we move the card to passed?
[15:34] <davmor2> rvr yeap
[15:38] <Mirv> sil2100: the bot announced done, but the job is itself doing the diff:s still - https://ci-train.ubuntu.com/job/ubuntu-landing-012-1-build/122/console - I guess I should wait for the diff:s to finish, or is that needed?
[15:40] <sil2100> Mirv: I would wait ;)
[15:41] <Mirv> ok
[15:43] <sil2100> om26er: I restored the entry - can you check if the spreadsheet saved it?
[15:44] <om26er> sil2100, yep, I see it now. Thanks a bunch :)
[15:44] <sil2100> You're welcome :)
[15:44]  * sil2100 off again
[15:45] <Mirv> sil2100: now running publish again, let's see..
[15:45] <Mirv> sil2100: hopefully you're better soon!
[15:46] <Mirv> sil2100: still same error :(
[15:46] <Mirv> sil2100: robru: https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/72/console
[15:46] <sil2100> huh?
[15:47] <sil2100> :|
[15:48] <sil2100> Mirv: this error means that the train didn't fill in one of the fields in the sync file
[15:48] <Mirv> and I ran full build job on Sat
[15:49] <Mirv> sil2100: any ideas what could be done?
[15:49] <sil2100> I think we might be able to hack around it, but I'm trying to find the file first
[15:50] <kenvandine> "The current browser does not support this feature. Please upgrade to a newer browser."
[15:50] <kenvandine> trying to create a silo...
[15:50] <Mirv> kenvandine: not yet another Chrome:ism...
[15:50] <kenvandine> it is chrome :)
[15:50] <Mirv> well that's refreshing for a change :D
[15:51] <sil2100> Mirv: hm, actually I don't see the packagelist file at all! :O
[15:51] <sil2100> We could dive into the code and try fixing that, but robru will be around soon so I guess he can do it with less effort
[15:52] <sil2100> Mirv: we'll publish the silo once the issues are dealt with :)
[15:52] <Mirv> sil2100: so nothing could generate the packagelist while waiting? maybe prepare + build?
[15:53] <sil2100> Mirv: I don't know how the new jobs work, robru rewrote all the logic ;) In the past those were generated during the publish job
[15:53] <sil2100> From the config and .project files
[15:53] <Mirv> I see robru has done some changes to https://code.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk in the last 24h
[15:53] <sil2100> Now? I don't really know, but I would suspect it to work the same
[15:53] <Mirv> possibly redeploying some older version would work
[15:54] <Mirv> he actually was here already but then went back to bed :)
[15:56] <Mirv> sil2100: but ok, I hope robru happens to be here back soon so we can publish the silo
[16:13] <om26er> abeato, Hi!
[16:13] <abeato> om26er, hi
[16:13] <om26er> abeato, while running the TestPlan for urfkill, re: silo 16 the last test fails
[16:14] <om26er> https://wiki.ubuntu.com/Process/Merges/TestPlans/urfkill
[16:14] <om26er> if I set modem to offline, it cannot be brought back up by going to flight mode and coming back. I have to bring it back up manually with the command.
[16:15] <abeato> om26er, ok, well, that concrete test case was introduced to test bug #1427439
[16:16] <abeato> om26er, and the fix has not landed yet
[16:16] <abeato> so the fact that it fails is not a surprise
[16:16] <om26er> abeato, aah, ok. I can continue with ofono testing then.
[16:16] <om26er> abeato, thanks
[16:16] <abeato> om26er, the best thing to do will be to add a comment in the spreadsheet
[16:17] <abeato> om26er, yes, I think so
[16:17] <om26er> abeato, yes, that'd be helpful.
[16:34] <jhodapp> sil2100, can you please reconfigure rtm silo 2 as well?
[16:36] <ogra_> jhodapp, he is sick
[16:36] <jhodapp> oh bummer
[16:36] <ogra_> either Mirv does after hours or you have to wait for robru
[16:36] <jhodapp> k
[16:36] <jhodapp> Mirv, ^
[16:40] <jhodapp> or robru ^
[16:45] <sil2100> jhodapp: on it
[16:45] <jhodapp> thanks sil2100
[16:45] <sil2100> ^ spreadsheet again going crazy
[16:45] <ogra_> sil2100, shouldnt you be in bed ?
[16:45] <sil2100> ogra_: I'm sick but looking here from time to time
[16:46] <sil2100> GEH, great, spreadsheet reverted itself ONCE AGAIN
[16:47] <sil2100> jhodapp: can you refresh the spreadsheet and check if all the merges you added are in the rtm silo line?
[16:47] <sil2100> jhodapp: since the spreadsheet just reverted itself
[16:47] <sil2100> robru, slangasek: ^
[16:48] <jhodapp> sure
[16:49] <jhodapp> sil2100, yeah it did revert, let me update it
[16:49] <sil2100> jhodapp: sorry about that, we can't do anything about the issues google is having...
[16:50] <jhodapp> sil2100, np, ok it should be updated
[16:54] <sil2100> jhodapp: should be updated
[16:54] <sil2100> The silo, I mean
[16:54] <sil2100> s/updated/reconfigured
[16:55] <jhodapp> sil2100, thanks
[16:55]  * sil2100 off again
[16:55] <ogra_> get well
[16:56] <robru> sil2100: I'm not feeling so good myself. I'll snooze for a bit then cover train stuff shortly
[17:08] <pmcgowan> sil2100, +1 to push ota-2 to rc
[17:09] <Mirv> robru: ping me when you can look at the 012 problem
[17:09] <sil2100> pmcgowan: o/
[17:10] <sil2100> robru: ok, seems like some trainguard-sickness has struck us!
[17:10] <sil2100> pmcgowan: ok, publishing it in a moment
[17:10] <sil2100> robru: once you're up, please take a look at Mirv's Qt silo, the train is doing something funny it seems
[17:15] <john-mcaleely> sil2100, thanks
[17:19] <rvr> rsalveti: I tested silo 15, looks ok. When the spreadshit is fixed, I'll approved it.
[17:21] <rsalveti> rvr: great, thanks
[17:21] <rsalveti> sil2100: any news on that topic?
[17:23] <rvr> robru: Can I sign off silo 15 in the spreadsheet?
[17:33] <sil2100> rsalveti: which topic do you have in mind?
[17:34] <ogra_> sil2100, i would guess the spreadsheet
[17:34] <sil2100> Sadly, no... if this doesn't get any better, we'll have to migrate to another spreadsheet
[17:34] <sil2100> We did that once because of such issues already
[17:34] <rsalveti> yeah
[17:34] <rsalveti> we want to land silo 15 basically
[17:34] <ogra_> move to libreoffice !
[17:35] <rvr> lol
[17:35] <ogra_> then you can blame sweetshark for all breakage ;)
[17:35] <kenvandine> sil2100, is this the same issue preventing me from creating a silo in chrome?
[17:35] <sil2100> rsalveti: I think it can land normally :) The problems usually are related to the spreadsheet reverting itself, but the publishing bits should be ok
[17:35] <sil2100> kenvandine: maybe... are you getting a fatal error?
[17:35] <kenvandine> yeah, says the browser needs to be upgraded
[17:35] <rsalveti> sil2100: guess the question was more to CI changing the state to approved
[17:36] <kenvandine> Mirv didn't sound surprised
[17:36] <rsalveti> so we can land the silo
[17:36] <sil2100> rvr: try changing it to signed off, let's see if it persists
[17:37] <rvr> The action you're trying to perform is causing a fatal error and cannot be performed.
[17:37] <rsalveti> geez
[17:37] <rvr> Let's see, it's green.
[17:39] <kenvandine> sil2100, oh... my landing request seems to have been lost on the spreadsheet
[17:40] <kenvandine> it was line 55 a little bit ago
[17:40] <rsalveti> Mirv: did we publish qt 5.4.1?
[17:41] <ogra_> there was supposed to be an RTM meeting where this should be decided
[17:42] <kenvandine> sil2100, should i bother adding it to the spreadsheet again?  or wait until you guys figure out what's going on?
[17:43] <rsalveti> ogra_: we decided we should land it
[17:43] <rsalveti> it seems mirv tried to land it
[17:43] <popey> sil2100: https://plus.google.com/u/0/+SzymonWaliczek/posts/Fr7jfr2somX
[17:43] <ogra_> rsalveti, right, i dont think Mirv will hit the button and go into his EOD though ... i would expect him to do it tomorrow monring instead
[17:43] <popey> see comment from charles about https://code.launchpad.net/~charlesk/indicator-datetime/lp-1425297-prevent-gdbusproxy-type-init-deadlock-rtm-14.09/+merge/251372
[17:44] <sil2100> kenvandine: I would say try re-adding it for now
[17:44] <rsalveti> Can't publish: Critical data missing from packagelist
[17:44] <rsalveti> Perhaps try a WATCH_ONLY build.
[17:44] <sil2100> Maybe it was the last problem
[17:44]  * sil2100 off sick
[17:44] <kenvandine> ok
[17:44] <rsalveti> ogra_: guess that's how the spreadsheet problem started
[17:44] <ogra_> ouch
[17:45] <Mirv> rsalveti: ogra_ we need robru to fix the train
[17:45] <charles> popey, +1 :-)
[17:45] <rsalveti> go robru
[17:45] <rsalveti> :-)
[17:45] <kenvandine> grr... can't add it, i get the fatal error now
[17:45] <Mirv> rsalveti: ogra_ I would push the button as soon as it's possible
[17:45] <ogra_> Mirv, doing a nightshift ?
[17:45] <sil2100> john-mcaleely: the krillin image should be now copied successfully!
[17:45] <ogra_> .oO( the bad influence of having cats)
[17:46] <john-mcaleely> sil2100, looks good so far
[17:46] <Mirv> ogra_: well I'm trying to be available as long as I can. kubuntu is now blocked by waitimg for Qt to land too
[17:47] <ogra_> ouch, ok
[17:47] <sil2100> Ok, let me take a look at what could be wrong with the publish job
[17:48] <popey> charles: just spoke to pat, so sent a mail and cc'ed you
[17:52] <sil2100> Mirv: I might have an idea how to fix this with a hack
[17:52] <kenvandine> after each field i get the fatal error, but then it seems to save
[17:54] <kenvandine> queuebot was notified i added it, but chrome complains if i try to close the tab that i have unsaved changes
[17:54] <kenvandine> this spreadsheet is having some issues :/
[17:55] <sil2100> kenvandine: yeah, as per the topic
[17:56] <kenvandine> can anyone else confirm that line 54 looks complete before i force close the tab?
[17:56] <kenvandine> it says all changes have been saved...
[17:56] <Mirv> sil2100: ok..
[17:56] <kenvandine> but complains if i try to close it
[17:58] <Mirv> kenvandine: looks ok, better copy-paste the MP:s anyway as it's reverting itself sometimes
[17:58] <kenvandine> yeah, lost that once before already :)
[18:00] <sil2100> Mirv: hah, I see what's b0rken
[18:01] <sil2100> I mean, I don't know what caused that still
[18:02] <kenvandine> woot... brute force to get a silo :)
[18:02] <sil2100> OUCH
[18:02] <ogra_> sil2100, google does :)
[18:02] <ogra_> just google it :P
[18:03] <sil2100> Mirv: ok, it seems I need to rebuild qtmir and qtmir-gles
[18:03] <sil2100> As it was missing the .project files for those...
[18:04] <sil2100> Mirv: my bad, I could have done a WATCH_ONLY build with qtmir qtmir-gles, but I didn't suppose that there are any packages in the silo that are not source uploads ;/
[18:04] <sil2100> Mirv: I should have double checked
[18:05] <sil2100> Mirv: anyway, once it finishes the rebuild I hope the silo will be ready for a republish
[18:08] <Mirv> sil2100: oh, ok... interesting
[18:12] <Mirv> rsalveti: oh no, you published ciborium :(
[18:12] <Mirv> that delays Qt even longer
[18:14] <rsalveti> Mirv: sorry, thought that was blocked
[18:14] <rsalveti> Mirv: can't we just trigger a rebuild? should be fast
[18:15] <sil2100> Crap, the qtmir-gles merge needs updating
[18:15] <sil2100> Mirv: can you update https://code.launchpad.net/~timo-jyrinki/qtmir/gles_sync_qt541/+merge/252690 ?
[18:15] <Mirv> rsalveti: I did that, maybe it's not a big package
[18:15] <sil2100> Mirv: 0.4.4+15.04.20150317-0ubuntu1  is the version
[18:15] <sil2100> (new version)
[18:17] <rsalveti> Mirv: small one, quick to build
[18:17] <Mirv> sil2100: done
[18:17] <sil2100> Mirv: thanks! Let me re-build that
[18:18] <Mirv> rsalveti: yup
[18:19] <jhodapp> sil2100, Mirv the reconfig on rtm silo 2 isn't working
[18:20] <jhodapp> the spreadsheet seems to take the changes, but it's building the old silo config
[18:38] <robru> Mirv: blah, sorry, you still around?
[18:39] <Mirv> robru: still around but sil2100 probably figured out what to do so hopefully ready soon
[18:39] <Mirv> jhodapp: sorry you need to wait for that guy ^ to catch up :) sil is sick and I'm not very available for anything extra
[18:39] <robru> Mirv: hm yeah unfortunately that safety check I put in to prevent publishing broken packagelists also prevents the broken packagelist from being inspected.
[18:40] <robru> jhodapp: yeah sorry I'm also sick and just trying to catch up on apprently everything is exploding
[18:42] <Mirv> robru: yeah just the error message wasn't clear enough for a dummy person, ie that it needs watch_only with package names specified apparently, I only did without
[18:42] <sil2100> robru: the problem was that some projects were missing .project files
[18:43] <robru> Mirv: hm, no, when you WATCH_ONLY that should act on all packages whether you specify any or not...
[18:43] <sil2100> I wonder what has caused that
[18:43] <jhodapp> robru, ok any idea what's going on...am I just out of luck until you get a chance to look at it?
[18:43] <robru> jhodapp: yeah sorry the spreadsheet is really horrible. what do you need, a silo reconfigure? email me the details (mp list / siloname etc) and I'll punch it in by hand
[18:47] <jhodapp> robru, yeah just for silo 2 rtm
[18:48] <robru> Mirv: I can't imagine why .project files would be missing...
[18:48] <jhodapp> robru, the list still looks good in the spreadsheet
[18:48] <robru> jhodapp: ok one sec
[18:48] <jhodapp> robru, just doesn't seem to actually reconfigure
[18:50] <robru> jhodapp: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-002-0-reconfigure/10/console does this list look right? there's a very real possibility that the spreadsheet isn't syncing correctly and thus the mp list you see in the spreadsheet is different than the one I see. if that list is wrong, please email me the correct list
[18:50] <jhodapp> robru, ok
[18:50] <jhodapp> let me look
[18:50] <jhodapp> robru, nope, not correct
[18:51] <jhodapp> robru, emailed you the list
[18:51] <robru> jhodapp: thanks
[18:51] <jhodapp> robru, no thank you, and hope you feel better soon
[18:52] <robru> jhodapp: thanks. https://ci-train.ubuntu.com/job/prepare-silo/4390/console that should do it for you then
[18:53] <jhodapp> robru, awesome, that looks correct thanks!
[18:53] <robru> jhodapp: ok just don't hit build yet because it's not quite finished
[18:53] <jhodapp> ok
[18:54] <robru> jhodapp: ok, should be good to build now
[18:54] <jhodapp> cool
[18:54] <jhodapp> thanks
[18:54] <robru> you're welcome
[18:55] <robru> Mirv: what's going on with qtmir-gles now? you rebuilt it? it's failing? wat?
[18:57] <Mirv> robru: well sil2100 didn't realize he wouldn't have needed to do a real rebuild. now that he did, apt has changed it behavior and the package needs some of the same dependency magic as uitk-gles needed earlier
[18:58] <robru> Mirv: so if there's a new build, how long will it take you to verify it? just a quick smoketest?
[19:01] <robru> bah
[19:03] <robru> Mirv: I've got a branch at least that'll make that publish error more informative
[19:07] <robru> Mirv: ok well, once you're happy with the qtmir-gles rebuild, I can't promise that publishing will work, but at least if publishing fails again it'll tell us specifically which package is busted and which data field is missing.
[19:11] <jhodapp> robru, there was one MR missing from both rtm silo 2 and ubuntu silo 23: first make sure that both are the list I provided you and then please add this MR: https://code.launchpad.net/~phablet-team/media-hub/use-transact-method/+merge/253062
[19:11] <robru> jhodapp: sorry I don't understand. you say "both" and then only list one mp?
[19:13] <jhodapp> robru, both silos
[19:13] <robru> jhodapp: you have the same set of mps for vivid and rtm? how does that work?
[19:13] <robru> jhodapp: I only reconfigured the rtm one...
[19:14] <jhodapp> robru, yep, same list
[19:14] <jhodapp> robru, it works :)
[19:14] <robru> jhodapp: k hang on
[19:14] <jhodapp> thanks
[19:14] <Mirv> robru: quick smoketest indeed
[19:14] <Mirv> for a nochange rebuild
[19:16] <robru> jhodapp: https://ci-train.ubuntu.com/job/prepare-silo/4391/console ok does that look right? that one's for rtm
[19:16] <robru> jhodapp: I guess that works for building but you can't actually *land* both those silos since they'll have conflicting changelog contents when you try to merge to the MP destination
[19:17] <jhodapp> robru, looks right to me
[19:17] <robru> jhodapp: ok I'll do the vivid one now
[19:17] <jhodapp> robru, yes, we won't be landing the rtm one, only using it for testing
[19:17] <robru> jhodapp: ok cool
[19:18] <robru> jhodapp: https://ci-train.ubuntu.com/job/prepare-silo/4392/console ok should be good to go for vivid too
[19:19] <jhodapp> robru, looks good there too, thanks!
[19:20] <robru> jhodapp: you're welcome
[19:35] <robru> Mirv: no diffs?
[19:37] <robru> Mirv: I don't understand why you cancelled the build and started a new one
[19:38] <Mirv> robru: watch only didn't work, it used old version number for ciborium
[19:38] <Mirv> robru: ie watch only doesn't pick up if manual sources were updated
[19:39] <robru> oh hmmm
[19:39] <davmor2> Mirv: robru: I hate the spreadsheet now it keeps resetting, sending out another set of ticket and resetting all the stats we set to tested :(
[19:39] <robru> davmor2: yeah that sounds like the spreadsheet to me
[19:39] <davmor2> robru: oh it is
[19:40] <robru> davmor2: what's remarkable is not how bad it is today, but how we somehow managed to make it 6 months without these issues. it used to be like this *constantly*
[19:41] <davmor2> robru: hahaha
[19:52] <robru> Mirv: how did you ever do this before ci-train? ;-)
[19:53] <Mirv> robru: https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/74/console
[19:55] <Mirv> robru: can you hack it to work?
[19:55] <robru> Mirv: let me poke at the silo
[19:57] <robru> Mirv: so the problem appears to be that sip4 is in the PPA but not actually in the silo config. and as a result of that, there's no corresponding sip4.project that the publish job relies on for the info that it needs to publish.
[19:57] <robru> Mirv: so add sip4 to the silo config, reconfigure, build with PACKAGES_TO_REBUILD=sip4 (but *not* watch_only) and then the publish should work
[19:58] <Mirv> robru: omg..
[19:59] <robru> Mirv: unless you don't need sip4; then just delete it from the PPA and the publishs hould be fine
[19:59] <Mirv> robru: nope, it's required
[20:00] <robru> Mirv: ok, now that I see what's happened here I'll put in an even better error message.
[20:01] <Mirv> robru: that might help a bit yes :D
[20:11] <Mirv> phew..
[20:12] <Mirv> now with luck kubuntu will also be unblocked in a few hours for their kf5 upgrades if the migration goes well
[20:18] <robru> Mirv: hrm, ok I pushed a fix that makes it say "check that foo is in the silo config", obviously it would be even better if it checked that itself, but the part of the code where it's doing this test doesn't have access to the full silo config, so it'll take some refactoring to make that better. For now though it should be clear what's going on at least.
[20:21] <robru> Mirv: https://ci-train.ubuntu.com/job/check-publication-migration/100943/console YES! one in the NEW queue, rest in proposed. none in the abyss ;-)
[20:26] <Mirv> robru: thanks! and yes, so it seems.
[20:26] <robru> Mirv: you're welcome, sorry it took me so long to wake up and fix that
[20:30] <robru> Mirv: what's the deal with qtwayland? is that going to be blocked in NEW for a long time, and if so, how horrible will it be when the rest of the silo migrates and that's the last bit left?
[20:31] <Mirv> no problem, it was complex anyhow with pieces moving.
[20:32] <Mirv> robru: ScottK knows about it and will probably quickly approve. it's also quite independent.
[20:32] <robru> Mirv: k, just remember that the NEW queue doesn't actually store the package, so if you merge it prematurely (eg to land the qtmir branches) then qtwayland will just be lost to the ether.
[21:08] <dobey> ToyKeeper: hi! are you around?
[21:08] <ToyKeeper> Hi.
[21:10] <dobey> ToyKeeper: hi, i have a branch which i think will solve the "add credit card" issue you reported (lp: #1421421). would you mind taking a few minutes to test it when i can get a click for you, to verify if it fixes the problem for you?
[21:11] <ToyKeeper> dobey: Yes, I can probably do that after I finish the sacrificial ritual I'm doing...  rewiring a new phone for power testing.
[21:11] <dobey> oh fun :)
[21:12] <dobey> don't burn your fingers
[21:47] <dobey> ToyKeeper: ok. jenkins is being super slow again i guess. i've made https://code.launchpad.net/~dobey/pay-ui/js-dialogs/+merge/253280 for my branch to get a click from jenkins for you to test with. if it happens to build the package reasonably soon and you can test it, that would be awesome. feel free to leave any comments on the MP or bug and i'll see them. thanks!
[21:49] <dobey> time for me to go. later
[21:50] <ToyKeeper> dobey: I can only test the actual bits which are proposed for landing.  If that's not the exict build to be used, it doesn't help much.
[21:50] <ToyKeeper> s/exict/exact/
[21:53] <dobey> ToyKeeper: i just need to verify if this is the reason you were not able to add a credit card before when the bank sent you to the other web page. i don't want to waste time fixing up the test infrastructure to be able to add tests for this, and then have it not actually fix the problem. so if you can install the click which gets built there and verify if you get the dialog popped up when you try to add the card which result
[21:53] <ToyKeeper> dobey: Oh, okay.
[21:54] <ToyKeeper> I made sure not to modify my account since then, in hopes I can still test it.  :)
[21:55] <dobey> ToyKeeper: ok great. thanks much :)
[23:05] <robru> brb
[23:56] <jhodapp> robru, ping
[23:57] <robru> jhodapp: hola
[23:57] <jhodapp> robru, hey, seems that this MR is still not listed/configured for RTM silo 2: https://code.launchpad.net/~phablet-team/media-hub/use-transact-method/+merge/253062
[23:58] <robru> jhodapp: blah. can you send me the complete list again?
[23:58] <robru> jhodapp: pastebin if you don't feel like emailing
[23:58] <jhodapp> sure
[23:59] <jhodapp> ok emailed
[23:59] <robru> thanks


[00:46] <cousteau> Qucs 0.0.16 was released in mid-March. Any chance it gets to Natty? if not, it would be nice to see it at least in Oneiric
[00:48] <JanC> cousteau: Qucs 0.0.15 is in natty now, and as we are less than a week from the release...
[00:48] <cousteau> ok, so Oneiric then
[00:48] <JanC> is it in Debian already?
[00:48] <cousteau> let me see
[00:49] <cousteau> hmm... nope
[00:50] <cousteau> don't know which changes will this version introduce, but after 2 years of development I'd expect some nice features...
[00:51] <JanC> or a single bugfix, depending on activity  ;)
[00:52] <cousteau> (then again, if they haven't released a new version in 2 years, maybe the project is a bit stalled)
[00:52] <JanC> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622758
[00:53] <JanC> so you're not the first to request it  ☺
[00:55] <JanC> seems like the Qucs devs are somewhat "release notes, what's that?"  :P
[00:57] <cousteau> well, they have a "News" section with some info
[00:59] <cousteau> it's a nice and easy to use software for electronic simulations... but it gets updated each... well, 2 years
[01:00] <jbernard> hallyn: nice work! thanks for all your help on that
[01:05] <hallyn> jbernard: thanks for not pointing out that the last bug was my own fault :)
[01:05] <hallyn> jbernard: thanks, have a good weekend
[01:05] <hallyn> i'm skeedaddling
[11:29] <bdrung_> hi, i have a problem with my dput upload: http://paste.debian.net/114872/
[11:30] <bdrung_> it is correctly signed with my key
[11:31] <BlackZ> bdrung_: I had the same problem but the package got uploaded
[11:32] <bdrung_> now i get the mails.
[13:29] <bambee> Hello, python-apt developers: in data/Ubuntu.info.in line 27, there is a missing description => software-properties-gtk displays "none" in updates tab, and software-properties-kde crashes (it should not, I agree, but I does because it tries to translate a None string). Add a description field solves the problem.
[13:29] <bambee> (I can be wrong...)
[13:31] <bambee> and all other templates have a description...
[13:34] <abhinav-> bambee: see this one https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/769364
[13:37] <bambee> abhinav-: it is exactly the problem :)
[13:37] <abhinav-> ah :)
[13:37] <abhinav-> its strange
[13:55] <bambee> see http://paste.ubuntu.com/597838/, there are two "natty-security", two "natty-proposed", two "natty-updates" with the same name and the same description, the only differences are the RepositoryType (deb-src). software-properties uses aptsources  which parses this file, then for each "Suite" it displays the name and the description => so we've duplicates options in the "updates" tab.
[13:55] <bambee> :)
[15:07] <mdke> I see that the Canonical Partner repository doesn't appear in software sources in natty - is it intended that users add the apt line manually or am I missing something?
[17:56] <Meep> Hi, anyone here interested in chasing down the kernel power regression.
[18:10] <lars_t_h> Meep, maybe you will be more lucky at #ubuntu-kernel
[18:10] <lars_t_h> You should also post a link to an error report
[18:20] <Meep> lars_t_h: Thanks.  Posted it to that channel with a ref to launchpad 760131
[23:24] <tomreyn> hi
[23:24] <tomreyn> what needs to happen to have this taken on? https://bugs.launchpad.net/ubuntu/+source/bitlbee/+bug/757008
[23:24] <tomreyn> with bitlbee-otr installed, bitlbee fails to start. and this package is unusable
[23:36] <tumbleweed> tomreyn: I can't reproduce that. From the Dependancies.txt it simply looks like a missing libotr2. Broken upgrade?
[23:37] <tomreyn> tumbleweed: thanks for looking into it. I haven't tried it for a while. Let me try it now
[23:39] <Ampelbein> looks to me like a missing Depends in bitlbee-plugin-otr
[23:40] <tumbleweed> Ampelbein: lol, I was in a sid chroot my bistake
[23:43] <tomreyn> tumbleweed: http://paste.ubuntu.com/598058/
[23:43] <tumbleweed> tomreyn: yeah I can see it now
[23:43] <tomreyn> but i agree about missing depends
[23:44] <tomreyn> do youthink there's a chance to get it fixed for natty?
[23:44] <tumbleweed> the plugin isn't linked again libotr2, and it should be. PRobably a result of the linker changes. Which may mean that it just needs a rebuild now (we've gone back to a conservative linker for release)
[23:44] <tumbleweed> yes
[23:44] <tomreyn> sweet
[23:44] <tumbleweed> yup, rebuilding works
[23:46] <tomreyn> what's the magic command for this again? 'apt-get -b source bitlbee-plugin-otr' or something?
[23:47] <tomreyn> oh --compile
[23:50] <Ampelbein> tumbleweed: are you preparing a no-change rebuild?
[23:52] <tumbleweed> Ampelbein: yeah
[23:53] <Ampelbein> btw, that error seems nasty as there is no way to auto-detect it at build time
[23:54] <tumbleweed> I guess that's a problem with any shared library plugin
[23:55] <Ampelbein> yeah, so in oneiric we must have an eye on packages with potential problems
[23:57] <tumbleweed> I'm still not sure exactly what caused this


[00:28] <isleshocky77>  I've been looking through the packaging documentation for a while now and still I'm running in circles. Could someone set me straight. I took the source of pidgin-libnotify and modified one file. Now I want to get a build in my personal launchpad ppa for x32 and amd64
[00:38] <micahg> isleshocky77: try #ubuntu-packaging
[03:46] <micahg> if I'm doing a new upstream release, is it worth merging from Debian?
[03:46] <micahg> sorry I should be clearer, the new debian release only was for 1 of the ubuntu revisions (i.e. we don't add anything, diff slighlty smaller)
[04:00] <rhpot1991> got a question on licensing, is it possible to get a non gpl compatible open source product into one of the ubuntu repositories?  the license in question is apple public software license.
[04:02] <micahg> rhpot1991: is it a free license?
[04:02] <rhpot1991> micahg: http://www.gnu.org/philosophy/apsl.html
[04:02] <RAOF> rhpot1991: If it's DFSG free, there's no problem (unless, of course, it does something stupid, like link against GPL libraries or somesuch).
[05:19] <ScottK> Of course GNU considers GFDL invariant a free license, so I wouldn't take their opinion as counting for much.
[05:27] <RAOF> Heh.
[07:02] <zooko> Yay! rockstar uploaded a package of Tahoe-LAFS 1.7.1 for Ubuntu!
[07:02] <zooko> Anybody want to test it out?
[07:06] <AnAnt> Hello
[07:54] <bilalakhtar> Why did M-o-M has to go down just before FF ?
[08:11] <dholbach> good morning
[08:20] <zooko> Who sponsored Tahoe-LAFS v1.7.1 to go into Maverick just now?
[08:20] <zooko> (I want to thank them on the tahoe-lafs mailing list.)
[08:24] <dholbach> zooko: https://edge.launchpad.net/ubuntu/+source/tahoe-lafs/1.7.1-0ubuntu1
[08:25] <zooko> Thanks!
[08:25] <zooko> Thanks, maco
[08:26] <zooko> Good night, folks (UTC-6)
[08:42] <AnAnt> dholbach: Hello
[08:44] <dholbach> hey AnAnt, sabah il cheer
[08:49] <AnAnt> dholbach: I think you meant: kheer
[08:50] <dholbach> AnAnt: that could well be :)
[09:59] <dholbach> Rhonda: does your offer for that git session still stand? :)
[10:00] <Rhonda> I hope so, but I don't have much time to prepare it properly.  %-(
[10:01] <Rhonda> Didn't sleep much this night neither, your young one wasn't working along.
[10:01] <dholbach> Rhonda: next week thursday?
[10:05] <nigelb> wow, git session.  Now that totally rocks :)
[10:15]  * Rhonda cries
[10:19]  * X3 throws Rhonda a chocolate tnafish
[10:47] <tumbleweed> it'd also have to ch
[10:47] <tumbleweed> grr, excuse that
[12:46] <pindonga> hi, I would like to seek sponsoring for bug #616025
[12:46] <pindonga> anyone iinterested?
[12:47] <AnAnt> looking
[12:51] <AnAnt> pindonga: in copyright file, upstream source can be https://launchpad.net/django-configglue
[12:51] <pindonga> ok,
[12:53] <AnAnt> also from upstream LICENSE file, it seems the copyright holder is Canonical Ltd., not Canonical ISD hackers
[12:54] <AnAnt> pindonga: ^ that is for the Copyright field
[12:54] <AnAnt> pindonga: the License field machine readable format copyright would be as follows:
[12:55] <AnAnt> License: LGPL-3
[12:55] <pindonga> the License was like that but lintian complained I wasn't referring to the common licenses
[12:55] <pindonga> Copyright: 2010 Canonical Ltd. would be ok?
[12:56] <AnAnt> followed by the disclaimer
[12:56] <AnAnt> as for Copyright: 2010, Canonical Ltd.
[12:56] <AnAnt> and you may even add a URL
[12:57] <AnAnt> for example. Copyright: 2010, Canonical Ltd. (http://www.canonical.com)
[12:57] <AnAnt> back to License
[12:58] <AnAnt> have a look at gst123 copyright file for example
[12:58] <AnAnt> http://packages.debian.org/changelogs/pool/main/g/gst123/gst123_0.1.2-1/gst123.copyright
[12:59] <AnAnt> is this tarball a repackage ?
[13:00] <pindonga> this would be the first package for ubuntu
[13:00] <pindonga> we had some previous packages in our own ppa for custom deployments
[13:00] <pindonga> but in those we never bothered to get the package right
[13:01] <AnAnt> I mean, no upstream tarballs released ?
[13:03] <pindonga> not yet, but I can do that if its needed
[13:03] <AnAnt> I'm not sure about that, but it seems to me that you removed the non-free icons, right ?
[13:03] <pindonga> mhhh
[13:04] <pindonga> actually I think the disclaimer in the license is wrong
[13:04] <pindonga> (I copied this from another project we opensourced)
[13:04] <pindonga> this  one doesn't have any images or icons
[13:04] <AnAnt> the disclaimer is in the LICENSE & the LP page
[13:04] <AnAnt> from LP:    Commercial subscription expires 2020-12-09
[13:05] <pindonga> this was an internal project first, and now I changed the license to LGPL3 as we were allowed to opensource
[13:05] <pindonga> I don't know why the "internal project" and "commercial subscription" did stick around
[13:06] <AnAnt> ok, maybe that should be changed upstream
[13:06] <pindonga> ok, so, let's recap please. I need to
[13:06] <pindonga> a) change the License field
[13:06] <pindonga> b) add a Dsiclaimer field
[13:06] <pindonga> c) change the Copyright field
[13:06] <pindonga> d) change the Upstream-Source field
[13:07] <pindonga> e) publish an upstream source tarball
[13:07] <pindonga> f) fix the LP project status
[13:07] <AnAnt> not a Disclaimer field, it is just a paragraph under License field, have a look at the example I gave you pleas
[13:07] <pindonga> g) fix the lincese disclaimer
[13:07] <pindonga> ah, ok
[13:07] <AnAnt> I'm not sure if it is required to publish upstream source tarball, but that would be useful for other distros anyways
[13:08] <AnAnt> as for f) what matters is fixing the LICENSE file in upstream tarball
[13:08] <AnAnt> but it would be rational to also fix the description in LP page
[13:09] <AnAnt> oh, you mentioned it in g) already !
[13:09] <AnAnt> ok, h) there is a generated patch
[13:09] <AnAnt> you can avoid that by removing the generated files in  clean target
[13:10] <AnAnt> I dunno how that is done with CDBS
[13:10] <pindonga> where do you see the patch?
[13:10] <AnAnt> debian/patches/debian-changes-0.3-0ubuntu1
[13:10] <pindonga> k
[13:10] <pindonga> I'll look into it
[13:10] <AnAnt> ok
[13:16] <AnAnt> pindonga: in the control file, you can drop XB-Python-Version field
[14:19] <pindonga> AnAnt, I just reuploaded the package, can you please give it another look?
[14:26] <pindonga> hi AnAnt , in case you didn't see my previous message
[14:26] <pindonga> pindonga> AnAnt, I just reuploaded the package, can you please give it another look?
[14:26] <pindonga> (I noticed you had a connectivity hickup)
[14:26] <pindonga> :)
[14:31] <pindonga> AnAnt, regarding the 'commercial support' thing, bac told me it's not so easy to remove... if this is still an issue for packaging, please contact him
[14:32] <AnAnt> pindonga: what commercial support ?
[14:32] <AnAnt> pindonga: the only issue was with this:
[14:32] <pindonga> in the license (in the launchpad page)
[14:32] <pindonga> we had 'internal project'
[14:32] <AnAnt> The image and icon files in django-configglue are copyright Canonical,
[14:33] <AnAnt> and unlike the source code they are not licensed under the
[14:33] <AnAnt> LGPLv3.  Canonical grants you the right to use them for testing and
[14:33] <AnAnt> development purposes only, but not to use them in production (commercially or
[14:33] <AnAnt> non-commercially).
[14:33] <pindonga> ok, that I removed
[14:33] <AnAnt> pindonga: you were talking about the LP page ?
[14:33] <pindonga> yeah, don't worry
[14:34] <AnAnt> ok
[14:34] <pindonga> just let me know if there is anything else I need to change on the package
[14:34] <pindonga> please
[14:36] <AnAnt> pindonga: third-party copyright should be noted in debian/copyright
[14:36] <AnAnt> pindonga: so you'll need a section like
[14:36] <AnAnt> File: path/to/file
[14:36] <AnAnt> Copyright: year, holder
[14:36] <AnAnt> License: whatever
[14:38] <AnAnt> pindonga: also please run lintian on the changes file, it will give you some good pointers
[14:39] <AnAnt> I don't understand why the resulting deb file has python (<<2.7) dependency
[14:40] <AnAnt> pindonga: by the changes file, I mean the one resulting from building the binary package (not just _source.changes)
[14:41] <AnAnt> or just run lintian on the source & binary packages
[14:41] <pindonga> AnAnt, sure, thanks
[14:42] <tumbleweed> AnAnt: python dependancies like that are a result of a python helper
[14:44] <AnAnt> tumbleweed: he's using python-central, I dunno about it
[14:45] <AnAnt> I'm used to python-support
[14:45] <tumbleweed> AnAnt: looking at th epackage now
[14:45] <AnAnt> thanks
[14:45] <AnAnt> brb
[14:45] <tumbleweed> pindonga: python-support is more widely used :)
[14:46] <pindonga> tumbleweed, I started off from another package :) is it important to use python-support instead of python-central?
[14:47] <tumbleweed> pindonga: it helps if you actually learn what you are doing rather than just modifying something else (but one has to start somewhere)
[14:47] <pindonga> yes, I agree
[14:47] <tumbleweed> more people know python-support, but both of them are slated to be replaced by dh_python2
[14:47] <pindonga> :/
[14:47] <pindonga> I'll try to make the next package use python-support
[14:48] <tumbleweed> pindonga: practically speaking for this package, there's nothing really python-central specific
[15:08] <tumbleweed> pindonga: full review on revu
[15:17] <AnAnt> tumbleweed: does debhelper compat level matter ?
[15:18] <tumbleweed> AnAnt: I don't know what caused python-central to misbehave either, I don't know it as well as -support or dh_python2
[15:19] <tumbleweed> AnAnt: it doesn't matter, it's just a case of why use an old version...
[15:19] <AnAnt> tumbleweed: ok
[15:21] <AnAnt> I don't understand what third-party license is there
[15:21] <AnAnt> running licensecheck says that every file is copyrighted by Canonical
[15:22] <pindonga> AnAnt, its because we copied over some code from django and adapted it, so we need to say it came from django source base
[15:22] <AnAnt> and changed the license to LGPL?
[15:25] <LucidFox> http://launchpadlibrarian.net/53483722/buildlog_ubuntu-maverick-i386.epiphany-browser_2.30.2-1ubuntu5_FAILEDTOBUILD.txt.gz
[15:25] <LucidFox> Any idea what could cause this?
[15:29] <micahg> LucidFox: yeah, there was some discussion about this in -desktop yesterday
[15:34] <micahg> bdrung: why do sponsorships get the assignee unassigned?
[15:39] <LucidFox> micahg> From the looks of it, WebKit-1.0.gir depends on JSCore version 1.0, while JSCore-1.0.gir claims 1.1
[15:39] <micahg> LucidFox: yeah an upload was done last night to change 1.0 to 1.1
[15:39] <micahg> LucidFox: https://launchpad.net/ubuntu/maverick/+source/gir-repository/0.6.5-6ubuntu6
[15:40] <pindonga> AnAnt, tumbleweed I just uploaded a new version, can you please re-check? (I hope I got it all this time)
[15:55] <pindonga> tumbleweed, shall I  look for someone else to finish the review (I don't want to bother you too much, but I would really like to make the maverick deadline)
[15:56] <tumbleweed> pindonga: I added more review
[15:56] <pindonga> ah, cool thanks
[15:56] <pindonga> tumbleweed, a few things
[15:57] <tumbleweed> pindonga: btw, does it work? :)
[15:57] <pindonga> 1. the thing with third-party: we copied some code over from django and modified it... the idea is to cope with django's license, mentioning that we used and modified original django code
[15:58] <pindonga> 2. re License: when  I run the lintian locally, it complains if I just use LGPL-3 saying I'm not referencing the common-licenses location
[15:59] <pindonga> how can I spot all those errors you found? running lintian locally gave no errors at all (I checked against the built package, the sources file and the dsc file)
[15:59] <tumbleweed> 1. so, it shouldn't only say "Copyright: Canonical"
[15:59] <pindonga> s/sources/changes/
[16:00] <tumbleweed> 2. instead of sying "given below" five the common-licenses path, then lintian knows you are doing the rgiht thing
[16:00] <tumbleweed> I could be using a newer lintian...
[16:00] <pindonga> I'm on lucid (maybe it's that?)
[16:01] <pindonga> :q
[16:01] <highvoltage> also, lintian doesn't always spot all the problems that a human can :)
[16:01] <tumbleweed> highvoltage: we try to make it, though :)
[16:01] <pindonga> tumbleweed, what do you mean by 'the watch file doesn't work?' / how do you test that?
[16:02] <highvoltage> *nod*
[16:02] <tumbleweed> pindonga: uscan --verbose --report
[16:03] <pindonga> ok, regarding the License: shouldn't it say the same thing as the LICENSE file? in that case, should I remove the LGPL code from it and point to the common-licenses file? if so, what happens on non-ubuntu distributions?
[16:03] <tumbleweed> pindonga: common-licences comes from debian
[16:04] <tumbleweed> it should say the same thing as LICENSE, yes, except that you can factor out the licence body, as found in common-licenses (look at other packages' copyright files)
[16:04] <maco> zooko: thank rockstar. he did the packaging. i just sponsored it
[16:05] <zooko> I did.
[16:05] <zooko> He and I have some plans to get packaging of Tahoe-LAFS for Ubuntu more automated.
[16:05] <maco> ok
[16:06] <zooko> So, that was Tahoe-LAFS v1.7.1. It has the major new improvement that it can be configured to act as an SFTP server, which means you can then point Nautilus at it and browse your decentralized filesystem graphically.
[16:07] <zooko> Now, Tahoe-LAFS v1.8.0 is in release-candidate mode. In all likelihood the current release--1.8.0c2--is going to be identical to the final 1.8.0 release.
[16:07] <zooko> (Unless someone reports a regression, security hole, or major bug.)
[16:07] <zooko> I'm toying with the notion of going ahead and announcing 1.8.0-final a few days early in the attempt to get 1.8.0 into Maverick.
[16:07] <zooko> The scheduled release date for 1.8.0 final is "approximately August 15".
[16:10] <zooko> Hm, I don't think I should cut the 1.8.0c2 test cycle short.
[16:10] <zooko> So, suppose I want to get 1.8.0-final included in Maverick, but it won't be released until the 15th (Sunday), then should I:
[16:11] <zooko> 1. ask to include 1.8.0c2 into Maverick right now
[16:11] <zooko> 2. file a FFE for 1.8.0-final, on Sunday
[16:11] <zooko> 3. forget about it and wait til Maverick+1
[16:11] <zooko> 4. other?
[16:13] <zooko> whoops gotta get ready for work. will check this IRC window soon...
[16:46] <pindonga> tumbleweed, what Standards-Version should I use? the one on lucid is 3.8.4
[16:56] <pindonga> tumbleweed, ok, I just pushed another version (please let me know when you looked at it)
[18:26] <paultag> lfaraone: ping, I was told to talk with you :)
[18:27] <paultag> lfaraone: I'm up in Debian, I work on the Fluxbox package ( only active maintainer right now ), and my DD is out ( his dad just died ). I'd love to get my new version uploaded in Debian in time to sync for Ubuntu. Is there any chance you could sponsor the upload / review the package. Currently there are 4 lintaian issues on the .deb because of upstream doc issues. I'm working on helping them resolve them
[18:29] <lfaraone> paultag: I'll be happy to take a look at it. Upload it to mentors and mail me the resulting email to myircnick at debian dot org
[18:29] <paultag> lfaraone: thanks! I'll do that right away.
[18:29] <lfaraone> paultag: these issues were present in the previous version, right?
[18:29]  * lfaraone will get to it in about 30 minutes, I was just walking out to lunch
[18:29] <paultag> lfaraone: yes, I have removed quite a few other lintian issues, and did a few bugfixes, and other fixes
[18:29] <paultag> lfaraone: sure, no problem. I'll be online
[18:30] <paultag> lfaraone: no new features
[18:30] <pindonga> anyone around that want to finish reviewing #616025?
[18:37] <fabrice_sp> pindonga, you have a generated patch in debian/patches: either make a clean patch or change it upstream. Maintainer field has the old value
[18:38] <pindonga> fabrice_sp, thanks, what do you mean by 'old value'?
[18:38] <fabrice_sp> it's not MOTU anymore
[18:39] <fabrice_sp> it's Ubuntu Developers<EMAIL_ADDRESS>[18:39] <fabrice_sp> Standards-version should be 3.9.1 also for maverick
[18:40] <fabrice_sp> also, do you really need a build dependency on python ?
[18:40] <pindonga> fabrice_sp, don't know, I think it was mentioned in the packaging guide
[18:44] <pindonga> fabrice_sp, when I remove the python build dep, lintian complains (E: missing-python-build-dependency)
[18:44] <pindonga> so I think I just leave it in there
[18:46] <fabrice_sp> because of distutils. it seems. ok
[18:51] <pindonga> fabrice_sp, ok, just pushed a new revision
[18:52] <fabrice_sp> ok
[19:03] <lfaraone> paultag: ah, maco referred you to me. I'll have to talk to her about that :P
[19:03] <fabrice_sp> pindonga, the watch file get a newer version from launchpad
[19:03] <fabrice_sp> is it normal?
[19:03] <pindonga> yes, I don't know why that is
[19:04] <maco> lfaraone: he needed someone that could make uploads to debian AND ubuntu happen... ergo: you
[19:04] <pindonga> ah, actually I think I need to replace the released source with the latest one
[19:04] <lfaraone> maco: thanks :P
[19:06] <paultag> lfaraone: haha
[19:06] <lfaraone> maco: by the way, when are you planning on leaving / returning from OLF?
[19:06] <maco> dunno yet
[19:06]  * lfaraone has school that week.
[19:07] <paultag> lfaraone: one time deal. My DD / all my DD friends IRL are busy :(
[19:07] <paultag> lfaraone: come on by, it will be great, I'm in Ohio
[19:07] <paultag> lfaraone: this counts for beer debt
[19:07] <lfaraone> maco: friday after 3:01, monday before 8:19 :P
[19:07] <maco> paultag: which you cant pay off til he turns 21 in 4 years?
[19:07] <paultag> Oh lawdy
[19:07] <lfaraone> paultag: right, I'll collect it in 4 years when I'm legal.
[19:07] <paultag> Sure thing.
[19:07] <maco> lfaraone: or in one year in europe?
[19:08] <paultag> maco: I had my first legal drink @ 16 in Germany
[19:08] <lfaraone> maco: sure. you going to debconf bosnia? :)
[19:08] <paultag> :)
[19:09] <paultag> maco: did you hear about the ubucon we'll be doing on friday @ olf ?
[19:10] <paultag> maco: akgraner was nice enough to get the ball rolling with that, it should be a blast.
[19:10] <pindonga> fabrice_sp, I think it finds a newer version beause lp doesn't really delete the old files? (even though I deleted them via the web interface?)
[19:11] <pindonga> if you notice it matched <IP_ADDRESS>  and now it matches <IP_ADDRESS> while looking for 0.3
[19:15] <paultag> lfaraone: any issues you see so far?
[19:15] <pindonga> fabrice_sp, if having a watchfile is optional, I'd go with removing it if it causes issues for approving the package
[19:15] <lfaraone> paultag: I'll let you know.
[19:15] <paultag> lfaraone: thanks :)
[19:16] <fabrice_sp> pindonga, I'd really prefer to have a working watch file :-)
[19:17] <pindonga> do you know how I can change it so that it takes the version in the url file? I tried that but it complains
[19:17] <pindonga> the download url is: http://edge.launchpad.net/django-configglue/trunk/0.3/\+download/django-configglue-0.3.tar.gz
[19:17] <lfaraone> paultag: is there a reason you're packaging a git snapshot?
[19:18] <pindonga> uscan complains about 'Use of uninitialized value $filepattern...'
[19:18] <paultag> lfaraone: yes, the 1.1.1 release is over 2 years old now, and there are a lot of debian patches I got merged into git mainline
[19:18] <paultag> lfaraone: it resultes in a much cleaner package imho. Is that wrong?
[19:18] <lfaraone> paultag: have attempts to get upstream to relese failed?
[19:18] <paultag> lfaraone: yes
[19:18] <paultag> lfaraone: I've tried over the last 4 months to get a .2 release, no luck
[19:18] <lfaraone> paultag: it's fine. you still have a tonne of patches though :)
[19:19] <paultag> haha, aye. I think the ones left are debian-isms
[19:19] <paultag> or ones upstream refuses
[19:19] <lfaraone> (well, only two, which is an improvement over the last version)
[19:19] <paultag> lfaraone: :)
[19:20] <lfaraone> paultag: if you're packaging git snapshots, you *should* write a get-orig-source rule to automate the process so that other people can reproduce your steps.
[19:21] <fabrice_sp> pindonga, this is because you have 2 times (.+) in your watch file
[19:21] <paultag> lfaraone: OK, I'll get that in the git.debian asap. Is it blocking this upload?
[19:21] <lfaraone> paultag: not per se, but I'll have to guess which repo etc oyu used so I can verify your tarball.
[19:22] <paultag> lfaraone: Ahha. git.fluxbox.org. I'll write the rule and get it in git.debian
[19:22] <fabrice_sp> pindonga, if you replace the first one with .*, it works
[19:25] <pindonga> fabrice_sp, cool, I'll just resubmit the package
[19:25] <pindonga> thanks
[19:27] <lfaraone> hmmm. how does one diff two *debian.tar.gzs.... debdiff tells me all the changes that were made, period, when I just want the changes that have been made in debian.
[19:32] <pindonga> fabrice_sp, ok, I just pushed the update
[19:33] <lfaraone> paultag: there's no commit on 2010-08-07 according to http://git.fluxbox.org/?p=fluxbox.git;a=shortlog;h=HEAD , did you mean the 2010-08-05 commit?
[19:33] <paultag> lfaraone: doh! yes, I forgot, I was playing in my PPA and had to get rid of the old revisions. That was just the date when I pulled the git tree down
[19:33] <lfaraone> paultag: if so, which? (I personally find it helpful to do "BASE_VERSION+gitDATE.REF" so there's no ambiguity.
[19:33] <paultag> lfaraone: yeah, I used the date of when I pulled
[19:35] <lfaraone> paultag: so you would want something like fluxbox-1.1.1+git20100805.0cc08f9, methinks
[19:35] <paultag> lfaraone: will that work if the sha sum on the same day for the next revision is "less" then the current revision?
[19:35] <paultag> lfaraone: e.g. a f8
[19:36] <lfaraone> paultag: No. But I'd expect you wouldn't be packaging two releases from the same day.
[19:36] <paultag> lfaraone: Very true
[19:36] <paultag> lfaraone: Should I change that, then?
[19:37] <lfaraone> paultag: if you are planning on that, feel free to do fluxbox-1.1.1+git20100805.0.0cc08f9, and incr the middle .0. :)
[19:37] <lfaraone> paultag: very yes.
[19:37] <lfaraone> paultag: it's important to have zero ambiguity about what version you're working with.
[19:37] <paultag> lfaraone: should I also include get-orig-source? I was just working on it, but I think it's broken. Could I exclude that for this revision?
[19:38] <paultag> lfaraone: OK. Let me fix that.
[19:38] <lfaraone> paultag: sure. I have a spare get-orig-source rule lying around, if you want it.
[19:38] <paultag> lfaraone: I'd love it
[19:38] <lfaraone> paultag: here's what I use for pianobar: http://bazaar.launchpad.net/~lfaraone/pianobar/debian/annotate/head:/debian/rules#L6
[19:39] <lfaraone> which also supports tags, as a matter of fact.
[19:39] <paultag> lfaraone: Ahha, I see what you're doing.
[19:40] <paultag> that's a lot better then what I was writing
[19:40] <lfaraone> paultag: that code has been adopted, rehashed, converted to different VCSs, so I'm surprised I got it working myself :)
[19:41] <fabrice_sp> pindonga, the package is not installable in Maverick, because python-configglue (>= 0.9), but maverick has 02dev-0ubuntu2it's expecting
[19:41] <paultag> lfaraone: I just noticed I don't have a debian revision on the package. Would it do me good to have it as 1.1.1-1+git... ?
[19:41] <pindonga> python-configglue 0.9 should have been proposed for maverick already
[19:42] <pindonga> let me check
[19:42] <lfaraone> paultag: uh, you do, the debian revision is at the end.
[19:42] <lfaraone> paultag: "fluxbox_1.1.1+git20100807-1"
[19:42] <paultag> Oh duh, my changelog
[19:42] <paultag> I was looking at my ls
[19:43] <paultag> lfaraone: I'm still just a programmer, sorry for the new-ish questions
[19:43] <fabrice_sp> pindonga, maverick still has 02dev
[19:43] <lfaraone> paultag: no worries. I'm only a packager. I'm still amazed anybody trusts me to upload anywhere, let alone Debian / Ubuntu :)
[19:43] <paultag> :P
[19:44] <paultag> lfaraone: you're keeping me in-line :)
[19:47] <pindonga> fabrice_sp, ok, I'm told they are updating maverick right now
[19:47] <pindonga> I'll ping you back as soon as I have word that it reached maverick
[19:47] <fabrice_sp> ok
[19:55] <paultag> lfaraone: I'm trying a build now. I'll put it to mentors if it builds OK
[19:56] <lfaraone> paultag: mk.
[19:59] <paultag> lfaraone: seriously, thanks so much. You really just saved my day :)
[20:02] <lfaraone> paultag: I live to serve.
[20:06] <paultag> lfaraone: warning: the current version (1.1.1+git20100805.0cc08f9-2) is smaller than the previous one (1.1.1+git20100807-1) <-- this was giving me flack
[20:06] <paultag> lfaraone: is it safe to pull the 5 to 7?
[20:06] <lfaraone> paultag: we have not uploaded it anywhere important, so yes.
[20:06] <paultag> OK
[20:06] <lfaraone> paultag: where did you get that warning?
[20:07] <paultag> lfaraone: in my dsc build. my pbuild failed, so I'm reviewing what went wrong
[20:17] <paultag> lfaraone: I really hate to bug you again, but I'm getting an error I'm not sure about
[20:17] <paultag> lfaraone: chmod: cannot access `/tmp/buildd/fluxbox-1.1.1+git20100807.0cc08f9/./configure': No such file or directory
[20:17] <paultag> lfaraone: I can paste the pbuilder log if that might help
[20:19] <lfaraone> paultag: I'm not a pbuilder wiz, but ask and maybe someone here can help.
[20:19] <paultag> Let me run it one more time catching stderr
[20:20] <paultag> Oh, wait
[20:20] <paultag> I think I know why
[20:38] <paultag> lfaraone: I'm having issues. can I email you when it's all set?
[20:40] <lfaraone> paultag: sure.
[20:40] <paultag> lfaraone: thanks, stupid build issues plus a long day of writing stupid code
[20:41] <paultag> lfaraone: thanks so much
[20:41] <lfaraone> paultag: no sweat.
[20:49] <fabrice_sp> what is the status of the sugar packages? Do we keep 0.86 and 0.84 packages or only 0.86?
[20:50] <fabrice_sp> it's for bug 616444
[21:14] <bdrung> micahg: because the sponsors assign the bug to themself before beginning sponsoring
[21:29] <micahg> bdrung: k, but why unassign?
[21:32] <Laney> because it's no longer their task to work on
[21:33] <bdrung> micahg: ^ and because only one person can be assigned
[21:33] <ajmitch> morning
[21:33] <bdrung> micahg: and noone assigned means that it's ready for sponsoring. if someone is assigned it means that he/she is working on it
[21:33] <bdrung> good evening ajmitch
[21:34] <micahg> bdrung: yes, but if one is actually doing the sponsoring, why isn't that considered fixing the bug?
[21:35] <bdrung> micahg: hä? i don't get it.
[21:35] <bdrung> bug fixing and assigning are two different things
[21:36] <ajmitch> the person who fixed the bug is the person listed in debian/changelog, generally
[21:36] <micahg> ah, ok
[21:36] <ajmitch> having someone assigned is a way of saying that this bug is being looked at by a particular person, don't touch it
[21:37] <ajmitch> whether that be the bug fixer or the sponsor
[21:37] <ajmitch> just a short-term lock, nothing really meant by it afaik
[21:38] <bdrung> yeah, it's a spin-lock :)
[21:38]  * micahg will remember when sponsoring
[21:39] <yofel> someone got time to look at a SRU for lucid? bug 616498   (FTBFS fix)
[21:40]  * ajmitch would if his laptop wasn't being useless & thrashing after a resume
[21:40] <yofel> heh
[21:40] <Laney> ajmitch: no! work on U1 in Debian!
[21:40]  * Laney covers your eyes
[21:40] <ajmitch> I'll just join the club & blame the fglrx drivers :)
[21:40] <ajmitch> Laney: that requires the same laptop
[21:41] <Laney> sure does
[21:41] <ajmitch> since that's my only up-to-date sid install
[21:41] <ajmitch> you seem eager to have U1 in?
[21:42] <Laney> yeah I'd like it on my work PC
[21:42] <Laney> and from a development POV, to reduce deltas
[21:42] <ScottK> Seems a bit odd to see excitement about clients for proprietary web services.
[21:42] <Laney> I'm quite relaxed about those really
[21:42]  * Laney visits twitter.com
[21:43]  * ajmitch uses the notes syncing more than the file sync, and that's pretty much just couchdb replication
[21:43] <Laney> Tomboy Web could be tasty though
[21:43]  * Laney will use a decent Free option if one exists
[21:43] <ajmitch> I saw a suggestion to have a default note in tomboy?
[21:43] <Laney> yeah, some advertising
[21:44] <ajmitch> I know that in debian you do need to configure note sync manually (typing in a URL)
[21:44] <bdrung> yofel: i don't think that's worth a sru. there must a more important reason than "fixes TFBFS"
[21:44]  * ScottK considers adding adverts to a bunch of packages.
[21:45] <ScottK> bdrung: I don't agree with that.  Fixing FTBFS is a good reason for an SRU.  Particularly in an LTS it improves the supportability of the archive.
[21:45] <yofel> bdrung: thanks to gorm.app missing, gnustep-devel is uninstallable in lucid
[21:45] <ajmitch> bdrung: even though there's no binary package in lucid due to that FTBFS?
[21:45] <micahg> bdrung: I'd say that depends on the likelihood of needing a security update
[21:46] <micahg> s/say/suggest/
[21:46] <ScottK> In fact, when we did the removal of unbuildable binaries in Lucid, we explicitly said they were eligible to be restored as an SRU if the FTBFS was fixed.
[21:47]  * Laney has fixed at least one like that
[21:47] <Laney> p.s. I hope it didn't sound like approved of advertising changes or wanted them in Debian/anywhere
[21:47] <Laney> ;)
[21:47] <Laney> s/like/like I/
[21:48] <jdong> sagemath people still seem upset at us
[21:49] <jdong> I'm assuming it's impossible to remove software from released repos?
[21:49] <ajmitch> why are they upset?
[21:49] <micahg> jdong: upload an empty package?
[21:49] <jdong> ajmitch: we apparently took a snapshot from sid that was not release quality
[21:49] <jdong> (e.g. badly broken)
[21:49] <ari-tczew> jdong: hello! did you come back from holidays?
[21:50] <pindonga> fabrice_sp, a quick question, assuming configglue 0.9 gets into maverick in the next 30min, would the django-configglue package need anything else done to it?
[21:50] <bdrung> https://launchpad.net/ubuntu/+source/gorm.app/1.2.8-1 looked like there were a binary package.
[21:50] <jdong> and nobody figured this out until after it froze
[21:50] <pindonga> I'll have to leave in a while and I want to make sure everything is done so it gets included
[21:50] <micahg> jdong: sagemath isn't in lucid
[21:50] <ajmitch> jdong: so is it worth updating, or removing?
[21:50] <jdong> micahg: jaunty and karmic, sorry.
[21:50] <micahg> oh
[21:50] <ari-tczew> jdong: could you review one my SRU bug?
[21:50] <ajmitch> old old releases
[21:51] <fabrice_sp> pindonga, I haven't seen anything, but you need 2 acks before upload
[21:51] <micahg> jaunty is almost EOL :)
[21:51] <jdong> ajmitch: I'm asking the maintainer that right now
[21:51] <pindonga> ok, anybody else that want to volunteer to review django-configglue ?
[21:51] <pindonga> :D
[21:51] <fabrice_sp> :-)
[21:51] <ajmitch> pindonga: url?
[21:52] <pindonga> http://revu.ubuntuwire.com/details.py?upid=8519
[21:52] <pindonga> ajmitch, do you want the bug url?
[21:52]  * ajmitch knows python-configglue, so django-configglue should go with it :)
[21:52] <ajmitch> sure
[21:52] <pindonga> ajmitch, https://bugs.launchpad.net/bugs/616025
[21:52] <yofel> bdrung: there was the binary package from karmic that was copied over, but it was removed after the rebuld test showed that it fails to build
[21:53] <jdong> ari-tczew: is it uploaded to -proposed yet?
[21:53] <pindonga> ajmitch, yes, python-configglue is being updated for maverick as we speak
[21:53] <bdrung> yofel: ok. i might look after processing the sync requests
[21:53] <ajmitch> pindonga: yeah I was talking to chipaca about it last night, I've uploaded the previous version to debian
[21:53] <pindonga> django-configglue uses latest python-configglue
[21:53] <pindonga> ajmitch, cool,
[21:53] <ari-tczew> jdong: no, it's require review by SRU team first, right?
[21:53] <yofel> bdrung: thanks :)
[21:54] <ajmitch> ari-tczew: it's been recently clarified that they find it easier to review an uploaded package
[21:54] <ajmitch> the policy was never very clear on the order of things
[21:55] <ari-tczew> ajmitch: interested in uploading to -proposed?
[21:55] <ari-tczew> :>
[21:55] <jdong> ari-tczew: right, as ajmitch said, I anounced a bit ago on -devel that after the SRU teams merged, it's now preferable to upload into the queue first, then review
[21:56] <ajmitch> ari-tczew: possibly, if someone else doesn't jump on it first :)
[21:56] <ari-tczew> ajmitch: you don't think which it's a simple!
[21:57] <ari-tczew> bug 464175
[21:57] <ajmitch> ari-tczew: sorry?
[21:58] <ari-tczew> ajmitch: ehkm, it's very simple SRU :) sorry for lack english
[21:58] <ajmitch> np :)
[21:59]  * ajmitch was about to ask where the debdiff was, until I saw the branches
[21:59] <Quintasan> Anyone knows if persia is on holidays or something?
[22:00]  * ari-tczew is looking also for persia
[22:00] <ajmitch> anyone else, feel free to grab that sru as well for sponsoring :)
[22:01] <bdrung> ajmitch: ping me once i have updated vlc and sponsored the sync requests. :)
[22:14] <pindonga> fabrice_sp, ajmitch , in case I don't get news word from Chipaca in the next 15 minutes, I will tell him to let you know when configglue reached maverick, so you can finish the review on django-configglue, ok?
[22:14] <ajmitch> pindonga: ok
[22:14] <pindonga> in case everything is ok, is there anything else on my side I should do?
[22:15] <ajmitch> at this point now
[22:15] <ajmitch> s/now/no/
[22:15] <fabrice_sp> pindonga, it's bed time for me. Sorry I'll check tomorrow morning
[22:15]  * ajmitch just needs to get time to sit down & look over it properly :)
[22:15] <ajmitch> it's only 9AM here, so I have a little bit of time
[22:15]  * fabrice_sp just needs to sleep :-)
[22:15] <pindonga> fabrice_sp, isn't today the deadline for maverick?
[22:16] <pindonga> if we still have time, I don't mind waiting a few days
[22:16] <pindonga> ok, Chipaca just told me configglue should be in maverick now
[22:16] <pindonga> just in time :)
[22:16] <fabrice_sp> If I remember correctly other cycles, freeze will happen tomorro morning
[22:16] <ajmitch> ok, I'll grab it (I need to stick 0.9 in debian anyway)
[22:17] <ajmitch> pindonga: is there any easy way to test django-configglue? :)
[22:17] <pindonga> ajmitch, once installed not really, as we are not including the test project in the deb file
[22:17] <pindonga> but if you grab the branch (or the source tar file)
[22:17] <ajmitch> is the test project public?
[22:17] <pindonga> yes
[22:18] <ajmitch> ok, that's good
[22:18] <pindonga> in the source tar file you should have the test project and a readme file on how to run the tests
[22:18] <ajmitch> just fetching now
[22:18] <fabrice_sp> pindonga, otherwise, you can find another sponsor. I really have to go now. Sorry
[22:18] <pindonga> fabrice_sp, ok, np. thanks
[22:18] <fabrice_sp> bye
[22:23] <ajmitch> pindonga: OK, I'll try & get this checked over in the next couple of hours - I've got a little bit of other stuff i need to do this morning as well :)
[22:23] <pindonga> ajmitch, I appreciate it
[22:24] <pindonga> do you think there is still time for it to get into maverick (assuming everything is ok)?
[22:25] <ajmitch> should be
[22:25] <pindonga> if you think there is a risk of it not getting included because another reviewer is required, would you mind requesting someone to look at it in addition to you?
[22:25] <ajmitch> otherwise freeze exceptions will be granted fairly readily if there's a good reason
[22:26] <pindonga> as I have to leave now, and won't be back for a couple of hours
[22:26] <pindonga> ajmitch, ok, thanks a lot
[22:26] <pindonga> I'll talk to you when I get back, or tomorrow
[22:26] <ajmitch> ok
[22:31]  * ajmitch really needs to get that dpkg backport tested & installed soon :)
[22:33] <jdong> there are days where I feel like my official job title is "coaster maker"
[22:33] <jdong> I hate optical drives
[22:34]  * micahg had that job for a while :)
[22:37]  * ajmitch wishes he could upgrade X
[22:37]  * Laney did earlier
[22:37] <shane2peru> I'm trying to help package a python app, It is all in the directory, and I created the deb with this: sudo dpkg-deb -b directory name.deb and it worked well, however the dev wants to be able to put files in the /home/$USER/app directory, how is this done?
[22:37]  * Laney dare not reboot
[22:37] <ajmitch> Laney: virtualbox-ose is holding me back
[22:38] <ajmitch> shane2peru: packages should never put files into home directories on installation
[22:39] <ajmitch> the app can place files there when run, but packages cannot
[22:39] <shane2peru> ajmitch, ok, this is a Bible application, with the ability to install other Bibles, or user material, like Sword does with .sword in the user directory, what is the proper way to do this?
[22:39] <ajmitch> the app should have a shared directory & per-user data directories
[22:39] <ajmitch> iirc sword would store bibles in /usr/share/sword or similar
[22:40] <shane2peru> ajmitch, so it would be better if the Bibles, and or user data were in /usr/share/bibleanalyzer then
[22:41] <shane2peru> it is a Bible app that is written in Python on windows, and is ported to Linux (specifically Ubuntu) but the dev is  in need of some help from a Linux guy, that is where I come in
[22:41] <ajmitch> yes, it would be better
[22:42] <ajmitch> also, you should never need to be using dpkg-deb to put together a binary package :)
[22:42] <bdrung> RainCT: ping
[22:42] <shane2peru> it is really odd to me, because there is no compiling necessary, I'm compiled apps, and that seems less odd to me then building a deb from a folder
[22:42] <RainCT> hi bdrung
[22:43] <shane2peru> ajmitch, ok, obviously I'm spilling out all my complete ignorance of this, what is the proper way to build a deb for a python app, and distribute it?
[22:43] <ajmitch> you need to make a source package which has the standard files (control, changelog, rules, etc) in a debian/ directory
[22:43] <ajmitch> the packaging guide has some good examples
[22:43] <ajmitch> if I can recall the URL :)
[22:44] <ajmitch> https://wiki.ubuntu.com/PackagingGuide/Complete
[22:44] <shane2peru> the dev didn't have a 64bit deb, so I started tinkering around, edited his control file to get the deb so that it would install on 64bit, because it is python, with no compiling, I don't know if it need to be architecture specific
[22:44] <Laney> it's best to get the *source* package and modify that
[22:45] <ajmitch> python packages like that should be created as architecture: all
[22:45] <RainCT> bdrung: what's up?
[22:45]  * bdrung shouldn't do too many thinks in parallel...
[22:45] <paultag> lfaraone: I have my stuff working. Should I email you again ( this is more of a ping then anything else ;) )
[22:46] <bdrung> RainCT: suspicious-source  license.
[22:46] <shane2peru> well, I don't know how he built his deb, but I extracted it and it was folders with the control files etc, I edited it to read all, and re-built the deb, which installed with no complaints on my 64bit setup
[22:46] <shane2peru> I also installed it on a 32bit setup, and it didn't complain
[22:46] <ajmitch> you extracted the binary package, no doubt
[22:47] <shane2peru> ajmitch, thanks for the link, I will read that, as I want to learn this to help him get his app out to Ubuntu,
[22:47] <bdrung> RainCT: do you allow relicensing the man page for it under the isc license?
[22:47] <shane2peru> right, I just right clicked the deb, and extracted, never done that before, apparently cli is ar or something of that, I'm not familiar with that.
[22:48] <paultag>  shane2peru ar x file.deb
[22:48] <RainCT> bdrung: Ah. Sure.
[22:48] <paultag> shane2peru: it's the old unix archive tool, and it was common at the time :)
[22:48] <shane2peru> paultag, right, I read that somewhere online.
[22:48] <paultag> shane2peru: in my younger years, I tried building a deb that way
[22:49] <paultag> it's hard
[22:49] <shane2peru> paultag, oh, with ar you mean, yeah, I could imagine.
[22:50] <shane2peru> one last question, with python type apps, you don't have to make configure and compile, is that correct?
[22:50] <shane2peru> actually it is wxpython
[22:50] <bdrung> RainCT: thanks. current change: http://pastebin.com/enCnWpbL the AUTHORS section is a little bit rough.
[22:50] <ajmitch> shane2peru: correct, they often have setup.py though
[22:50] <paultag> shane2peru: https://wiki.ubuntu.com/PackagingGuide/Complete
[22:50] <paultag> Oh shoot!
[22:51] <shane2peru> ajmitch, that is so odd for me, so then building a deb from the folders is the proper way to do that with python apps then?
[22:51] <paultag> That was going to be the python one
[22:51] <bdrung> RainCT: i failed to not mention my name twice
[22:51] <shane2peru> paultag, ohh, if there is a python specific link, I would love that!  Because seems as though they are not the same.
[22:51] <paultag> shane2peru: yeah, let me find it, I just lost it
[22:52] <ajmitch> shane2peru: you use tools like 'debuild' to build it from a source package, not using dpkg-deb
[22:52] <RainCT> bdrung: Heh.  «\fBsuspicious\-source\fP have been written by» -> «has been».  You may just remove my name from the manpage if you want.
[22:52] <paultag> shane2peru: https://wiki.ubuntu.com/PackagingGuide/Python
[22:52] <shane2peru> ajmitch, ok, thanks!!!  I will do some research on debuild later, I only ever used checkinstall before, and I don't think I can use that with a folder
[22:52] <shane2peru> paultag, thanks!!!
[22:53] <paultag> Sure, that guide is pretty complete
[22:53] <shane2peru> wonderfull!  Thanks guys, I'm sure I'll be back
[22:53] <bdrung> RainCT: is that really ok for you?
[22:53] <neeraj> I have requested sync of some packages which now I have found that will not work in maverick.
[22:54] <bdrung> neeraj: fix them ;)
[22:54] <neeraj> what will be the proper procedure for closing the bug
[22:54] <neeraj> bdrung, we have upgraded versions of those packages which will work :)
[22:55] <RainCT> bdrung: Yeah. What's left there, 5 lines? I can live with not getting mentioned for that ;)
[22:55] <bdrung> neeraj: are the not working version already synced?
[22:55] <neeraj> no, i filed a request today only
[22:55] <bdrung> RainCT: ~8 lines ;)
[22:56] <bdrung> neeraj: mark them as invalid and give a short reason for marking them invalid
[22:56] <bdrung> neeraj: which one are they? i am currently processing sync requests
[22:56] <neeraj> bdrung, Ok.  thanks :)
[22:57] <bdrung> neeraj: i just uploaded sugar-write-activity-0.86_70-1
[22:58] <neeraj> sugar-chat-activity-0.84
[22:58] <neeraj> bdrung,  LP Bug#616462
[22:59] <bdrung> neeraj: all other sync request of you are unaffected?
[23:00] <neeraj> bdrung, no. LP#616444 and Bug #616465 too.
[23:00] <neeraj> bdrung, rest are working properly to my best knowledge.
[23:25] <RainCT> bdrung: Oh, I've just seen you 'stole' my merge. Thanks :)              (manpages-de)
[23:25] <directhex> DktrKranz, is there any planned slowdown in debian NEW alongside the freeze?
[23:25] <ajmitch> apart from ftpmasters recovering from debconf? :)
[23:25] <bdrung> RainCT: :)
[23:26] <directhex> ajmitch, i don't know how many of them were at debconf. i make no assumptions of slacking, i merely ask if there's a plan to do other things in the short term
[23:26] <bdrung> RainCT: can i exchange it for vim?
[23:37] <norax> Hi
[23:39] <norax> If there is someone over there, just a question: Someone told me that when you submit a patch to launchpad you should subscribe to Ubuntu-Universe-Sponsors. Now it seems that this group is depreciated. Any alternative?
[23:39] <ScottK> norax: ubuntu-sponsors
[23:39] <norax> thank ScottK
[23:41] <micahg> hmm...I thought patches go through reviews and debdiffs go through sponsors
[23:42] <norax> well, I have submit a debdiff, but what is the difference?
[23:43] <micahg> norax: yeah, sponsors then, patches that are suggestions for fixing usually go through reviews that will attempt to upstream and make sure it works
[23:43] <micahg> debdiffs as tested fixes go through sponsors AFAIK
[23:50] <norax> hmmm, don't know. When I submit a patch, I create a debdiff and test it in my computer. I do not create a patch so other people can test and later create a debdiff to submit. I mean maybe I should subscribe just to reviews, and wait that it is tested from other people and later subscribe sponsors.


[18:26] <zaki> hey pavlushka
[18:26] <zaki> .uptime
[18:28] <zaki> pavlushka, I've now verified PayPal acc.
[18:28] <pavlushka> wow
[18:28] <pavlushka> zaki: so you buy international services now?
[18:29] <zaki> yea
[18:29] <zaki> pavlushka, what is this ubiquity-maybe.service for? :D
[18:31] <pavlushka> zaki: not for servers, it's for liveCD installer
[18:33] <zaki> ah
[18:33] <u-la-la> zaki: 2020-03-10 - 12:14:27UTC <pavlushka> tell zaki slow what? how and why?
[18:33] <u-la-la> zaki: 2020-03-10 - 12:59:02UTC <pavlushka> tell zaki the vm is faster now, there was an unneccessary kernel parameter defined in the /etc/default/grub in "GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity"" which was for GUI-desktop not meant for servers
[20:28] <pavlushka> zaki: night night
[20:34] <zaki> .uptime
[20:34] <u-la-la> I've been sitting here for 1:08:51 and I keep going!