[03:34] <histo> !search ipset
[03:58] <talldave> I’m thinking about installing Ubuntu Server 12.04 onto a single disk as RAID 10.    Advisable?
[04:01] <histo> !raid | talldave
[04:02] <talldave> thanks ubottu
[04:05] <talldave> histo why not?
[04:05] <histo> talldave: why not what?
[04:05] <histo> talldave: I'm curious as to how you're going to build a raid with one drive?
[04:05] <talldave> i assume !raid meant ‘dont do raid’
[04:05] <talldave> by splitting the drive into 2 partitions
[04:07] <histo> talldave: that's retarded
[04:07] <histo> talldave: A mechanical disk or ssd?
[04:07] <talldave> mechanical
[04:08] <histo> talldave: have fun killing your drive.
[04:08] <histo> talk about disk thrashing
[04:09] <talldave> thanks.  ‘not advisable’ would have worked
[04:09] <histo> That's what I said
[04:10] <histo> talldave: Think about it the disk has to write to one partition jump and write to another for every write etc....
[04:10] <histo> There is no benefit to doing that. You will actually lose speed
[08:17] <tomixxx7> hi, does someone know a good apt-get install tool to measure bandwidth between two ubuntu machines?
[08:18] <tomixxx7> i cannot use iperf, because of some port restrictions
[08:24] <histo> tomixxx7: ntop
[08:26] <tomixxx7> ty
[08:59] <lordievader> Good morning.
[09:03] <bekks> tomixxx7: iperf
[09:36] <sveta> tomixxx7, i think i use 'vnstat', it gives total stats without per-host
[09:38] <tomixxx7> ty
[13:04] <Lcawte> Hmm, is it possible to get a newer version of openssh-server on Ubuntu 12.04 without compiling it from source (a PPA or something?)
[13:05] <jrwren> it might be in backports. Why do you need a newer version?
[13:07] <Lcawte> I need the AuthorizedKeysCommand option but that's only in OpenSSH 6.2+
[13:17] <TJ-> Lcawte: You might want to check this PPA option out: https://launchpad.net/~li69422-staff/+archive/backports-for-precise/+packages
[14:52] <Lcawte> TJ-: Is there a way I can add the PPA and only install the SSH related packages (because I want to take say, the nagios-nrpe package from the main Ubuntu repos) ?
[14:54] <TJ-> Lcawte: I usually add the PPA, install the package I want, then disable the PPA until I want to do an update
[23:16] <jak2001> hi all, i have been installed/configured, openssh, my question is how to access via FTP via SSH? thanks  or you recommend install vsftpd?


[01:43] <ScottL> TheMuso, if you haven't germinated the seeds already, do you mind waiting until astraljava and cory resolve an issue?
[01:43] <TheMuso> ScottL: Not at all, haven't done them yet.
[01:44] <ScottL> astraljava, i will send an email to cory and cc you  about your concerns about gnome-panel in the desktop seeds
[01:44] <ScottL> astraljava, when you and cory resolve these concerns can you let TheMuso know so he can germinate the seeds?
[06:43] <astraljava> ScottL: Oh absolutely. I'll wait for Cory to respond first, though, but will have a look at merging the seed with Xubuntu's. I'm pretty sure Cory has some significant changes to it, though, so we'll see how it goes.
[09:16] <falktx> hi there
[11:01] <astraljava> Howdy falktx!
[11:14] <falktx> hey
[11:39] <ScottL> hi falktx
[11:40] <ScottL> astraljava, there are changes, like the lash->ladish transition, that are planned but i am waiting to update the seeds for these until we make the xfce transition first
[11:41] <ScottL> i'd like to keep it as simple as possible and not needlessly confuse any issue during this potentially difficult and trying time
[11:43] <ScottL> astraljava, i think cory might be at home today as well, we should try to PM him at some point and draw him into conversation about the seeds
[11:47] <astraljava> ScottL: Sounds good. I'll be traveling in about two hours, and for about four hours, so might not be available online until 1800 UTC, or 1300 for you.
[11:49] <ScottL> astraljava, okay, i'll see if you are about in +6 hours or so and then try to catch cory if he hasn't already
[11:54] <astraljava> ScottL: Sounds like a plan. :)
[18:01] <astraljava> scott-work: Any word from Cory?
[18:04] <astraljava> scott-work: Gonna walk the dog. It also seems that I got some company, so I'll be out soon. But I've got some time if we are all here for a bit at the same moment. If not, I'll read the backlog, and act accordingly over the weekend.
[18:30] <scott-work> astraljava:  i've tried to query him but apparently he's not been on IRC all morning :(
[18:48] <astraljava> scott-work: Okay. Well, I can do the merge with our desktop seeds tomorrow, and then I'll push it as it is. When you, Cory and whoever feels like taking part in that discussion, has voiced their opinions on the selections, we can tweak it to perfection, and let Luke know when it's ready.
[18:48] <astraljava> I'm out for this evening, but depending on how long I'll be, I will have a look at the channel and see if there's been any talk regarding the issue.
[18:48] <astraljava> So, later.
[22:30] <ScottL> bassburner, i'm going to look at the website this weekend and makes some decisions for a direction forward
[22:30] <ScottL> if anyone else is interested in helping please let me know and we can discuss
[22:31] <ScottL> ailo, are you still available to test alessio's 3.0 -lowlatency kernel?  i should finish my tests this weekend
[22:31] <ScottL> ailo, also have you made any progress on the documentation?
[22:31] <astraljava> ScottL: I can participate, but am not a real web person.
[22:32] <ScottL> should we take bite size chunks and you, holstein, and i can flesh out what we want to document for just a particular topic?
[22:32] <ScottL> this would make positive progress for us at least and help define some things
[22:32] <astraljava> Certainly.
[22:32] <ScottL> astraljava, that would be cool, i'll see if i can find the website again
[22:32] <ScottL> astraljava, oh, i meant the previous statement for ailo
[22:33] <astraljava> ScottL: Figured as much. :)
[22:33] <ScottL> but if you, astraljava, want to help with documentation that would be cool too :)
[22:33] <ScottL> astraljava, here is the current website demo: http://ubustu.exit66.com/
[22:33] <astraljava> ScottL: I intend to pay attention to the testing documentation, as agreed in the previous meeting.
[22:34] <ScottL> that's good :)
[22:34] <ScottL> that would probably be in the wiki.ubuntu.com documentation, the stuff ailo, holstein, and i are discussing is more user facing and probably in help.ubuntu.com
[22:34] <astraljava> Uh oh... way too colourful for my tastes. :D
[22:34] <ScottL> lol
[22:35] <astraljava> yeah I figured as much, also.
[22:36] <astraljava> The tweets thingie is great, though.
[22:36] <astraljava> Some problems reading some texts, that are of the same color than the dots in the background.
[22:37] <astraljava> Well, not real problems, but they make the font seem sort of messy.
[22:37] <ScottL> astraljava, those are good points and we should probably notate them somewhere for bassburner
[22:37] <ScottL> also:  https://wiki.ubuntu.com/UbuntuStudio/TaskWebRevamp#Rough_Site_Map
[22:38] <astraljava> That's mainly in the bottom, underneath the white block.
[22:38] <astraljava> Sure, sure.
[22:39] <ScottL> that last link was just a list of ideas to include with the website, not everything is to be included or viable
[22:39] <ScottL> we can sort through that and figure out what is most important right now and tenable
[22:39] <astraljava> Oh, and get the "Our best release yet!" out of there. 11.04 is most likely the worst release ever. Falls behind of Warty, even. And I didn't have sound for Warty. :D
[23:55] <holstein> ScottL: i dont need to be involved on the site, unless you need something i can help with
[23:55] <holstein> just put it up there.. looks awesome!


[01:00] <jayvee> zul: ping
[01:00] <zul> jayvee: pong
[01:02] <jayvee> zul: I was told to ping you with regards to a bug report of mine
[01:02] <jayvee> actually, looks like I got a response from somebody else, but this is it: https://bugs.launchpad.net/libvirt/+bug/528934
[01:02] <zul> jayvee: ok whats the bug report?
[01:03] <zul> can you attach the upstream bug report to it?
[01:05] <jayvee> zul: just done
[01:05] <jayvee> I was sure that I’d done it before, but I guess I mustn’t have.
[01:06] <zul> thanks
[01:06] <jayvee> I presume you’re ~zulcss on Launchpad? :)
[01:07] <zul> yep
[01:47] <getxsick> anyone around?
[01:48] <persia> !ask
[01:49] <getxsick> i'm reading that Ubuntu Policy and it's written about different package versioning schemes (Ubuntu uses ubuntuX). well, i just downloaded the source via apt-get source and what i see in debian/changelog, there is no that ubuntuX
[01:50] <funkyHat> getxsick: use dch -i to update the changelog, it will add an entry with the correct version number
[01:50] <persia> Which version do you have, for which package?
[01:52] <getxsick> persia: i'm updating scripts for pypy* packages, because we are releasing 1.2 version
[01:52] <getxsick> the last time we did it for long time ago and it was for Debian
[01:52] <persia> getxsick: Seems like Ubuntu is using the Debian source of that unmodified.
[01:52] <getxsick> persia: possible
[01:53] <persia> That's why you find that versioning.
[01:53] <getxsick> persia: at least, we are not really interested in supporting Debian, we would like to use launchpad PPA...
[01:53] <persia> It also looks like pypy was removed from Debian and that removal was synced to Ubuntu.
[01:53] <persia> Oh, then the version doesn't matter at all.
[01:54] <getxsick> ah
[01:54] <persia> In fact, I recommend using -0ppaN where N is incremented for each rebuild as the revision.
[01:54] <persia> But this really isn't the best place to ask about PPA stuff: we don't support PPAs.
[01:54] <getxsick> what if we would like to include pypy to next ubuntu release?
[01:54] <persia> If you'd like it in Ubuntu, I'll recommend putting it back in Debian: that's the easiest way.
[01:56] <getxsick> persia: why?
[01:58] <funkyHat> getxsick: because Ubuntu syncs from debian automatically
[01:59] <funkyHat> getxsick: also if you submit a package to Ubuntu and later a newer version gets uploaded to Debian that creates more work because someone has to check the the Ubuntu version doesn't have any changes that need to be kept.
[01:59] <funkyHat> woo long sentence
[02:00] <persia> getxsick: Because of what funkyHat said, and because there are no dedicated maintainers in Ubuntu, so unless something is particularly popular, it usually gets deleted after a while if it's not in Debian.
[02:00] <getxsick> we can maintain it, that's not a problem
[02:01] <persia> well, except you can't, unless you can continuously convince some developer to upload any changes.
[02:02] <persia> Based on past history it usually takes 18-36 months for someone pushing changes to only one package and not otherwise acting as an Ubuntu Developer to be granted upload rights to that package.
[02:02] <funkyHat> Also why do you want to leave Debian out?
[02:03] <persia> If you can maintain it, why not sign up as the Debian Maintainer.
[02:05] <getxsick> persia: actually i don't know, have to check in maling list ;) i just knew that there were some different opinions between us and them ;)
[02:07] <persia> Hrm.  Depends on the difference of opinion.  If it was mainly personal, we may be able to help work around that.  If it was technical, we tend to share their opinions.
[02:07] <getxsick> persia: it was 2-3 years ago
[02:07] <getxsick> anyway, our buildbots run under Ubuntu
[02:07] <persia> Things may well have changed.
[02:07] <getxsick> persia: sure
[02:08] <getxsick> well, i will talk with others what they think about
[02:08] <persia> Yeah.  I understand the goal is to get it in Ubuntu, and I support that goal, I just happen to think getting it into Debian is the easiest way to get it into Ubuntu and make sure it stays in Ubuntu.
[02:08] <getxsick> persia: ok. i understand this point
[02:09] <persia> But I'd be happy to help you try to get it into the Ubuntu 10.10 release if you really want, I just have a sense that without sorting the issue with Debian, it would be dropped for 12.04 if not sooner.
[02:09] <getxsick> persia: 12.04? :)
[02:09] <persia> Yes.
[02:09] <getxsick> isn't 2012?
[02:09] <persia> We plan things out a fair bit in advance.
[02:09] <persia> Yes.
[02:10] <getxsick> michael hudson (who is one of the pypy developer) said that it should be included in 10.10 AFAIR
[02:11] <getxsick> well, when do you freeze debian unstable for 10.10 ?
[02:12] <persia> Based on https://wiki.ubuntu.com/MReleaseSchedule it looks like 24th June.
[02:14] <persia> But we can pull new packages until 26th August, if we need, it's just not automatic.
[02:14] <getxsick> persia: cool
[02:14] <persia> I'd suggest targeting mid-late June, and leaving the rest as a gap for coverage if anything goes wrong.
[02:15] <getxsick> we are releasing final 1.2 by the end of March
[02:15] <getxsick> so it shouldn't be any problem
[02:16] <persia> Cool.
[02:24] <funkyHat> I'm looking at the merge report for sensors-applet https://merges.ubuntu.com/s/sensors-applet/REPORT - everything looks great, I'm just running a test build now. But I've found this bug https://bugs.edge.launchpad.net/ubuntu/+source/sensors-applet/+bug/380669 which wants to upgrade to 2.2.5-3
[02:24] <funkyHat> Should we upgrade to 2.2.5-3, or only to 2.2.4-2. ...5-3 is only in unstable
[02:27] <persia> funkyHat: Which one works better with lucid?
[02:28] <funkyHat> persia: I don't know. How do I grab the debian source packages for 2.2.5-3?
[02:29] <persia> pull-debian-source works, or visit packages.qa.debian.org and use dget or visit qa.ubuntuwire.com/multidistrotools and use dget or ...
[02:30]  * persia tends to open a sid schroot and apt-get source stuff
[02:31] <funkyHat> Ok, building 2.2.5-3 now
[02:37] <funkyHat> persia: well I've hit a limitation of using a VM which is I don't have any sensors, so I can't really test properly
[02:39] <funkyHat> Other than that I can't see any problems with 2.5.5-3
[02:39] <persia> Then you either need to find some testers, or upgrade :)
[02:39] <persia> Given that we're past FeatureFreeze, I'd recommend doing both.
[02:40] <funkyHat> I'm going to be buying a wacom tablet soon, and I heard that Lucid didn't support them a while ago... I'll have to investigate whether that's been resolved
[06:53] <AnAnt> Hello, could someone grant FFe to LP 530204 ?
[06:53] <AnAnt> especially it also closes LP 491784
[07:54] <dholbach> good morning
[08:22] <jayvee> hmm, no feedback from zooko or his team about the tahoe-lafs package
[08:45] <GheRivero> morning
[08:46] <wrapster> i have a control file like so.. http://pastie.org/855217 .. which in turn builds a lot of other pakcages.. and i wanted to say that in a particular pkg 'spjadbx' it conflicts with ss12.. So i enter that that pkg declaration and built that pkg..But when i tried installing it.. it fails saying that there is a file present in this pkg as well as another pkg(the very reason why i added conflicts)... and when i open the control file again.. the conflicts
[08:59] <siretart> bjsnider: exactly!
[09:00] <siretart> debfx: i've just filed a debian bugreport to not forget it! thanks for notifying me
[10:08] <debfx> siretart: okay, packaging branch should be ready for upload
[10:30] <hakaishi> Hi, I’d like to remove qt-shutdown-p from revu, since there is a newer package of it with a new name and is already uploaded to debian. What can I do, who can I ask (to remove it)?
[10:40] <hakaishi> Does nobody know?
[10:45] <hakaishi> X-P
[11:52] <falktx> hi there
[11:53] <falktx> I've sucessfully send a package to revu and it was accepted
[11:54] <falktx> now I need to fix a bug in the package
[11:54] <falktx> I've made the needed changes and it's ready for upload
[11:54] <falktx> how should I do it?
[11:54] <falktx> using 'dput ubuntu *.changes' doesn't work
[11:54] <falktx> ideas?
[11:55] <geser> let me guess, it complains that's it's already uploaded?
[11:55] <geser> dput -f ...
[11:55] <falktx> nope
[11:55] <falktx> it uploads
[11:56] <falktx> then I receive an email saying it was been rejected
[11:56] <falktx> message says: "The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?"
[11:56] <falktx> I am the maintainer of the package
[11:57] <falktx> I did try now just 'dput *.changes', no mail answer so far
[12:00] <falktx> the wiki revu page says I should manage the package through launchpad
[12:00] <falktx> but I guess it doesn't allow new uploads (?)
[12:01] <falktx> (just got the rejection mail again)
[12:01] <falktx> should I upload to REVU again ??
[12:02] <geser> ah, then you are not uploading to REVU but to the official archive
[12:02] <geser> "dput revu yourpackage_source.changes"
[12:03] <falktx> but I though I could just upload to universe and not going for the revu stuff all over again...
[12:04] <falktx> if the package is assigned to me, isn't there a faster way to do this?
[12:04] <geser> your package is already part of official archive?
[12:05] <falktx> yes
[12:05] <falktx> https://launchpad.net/ubuntu/+source/zyn
[12:06] <falktx> (this is the first time I do this, please be patient)
[12:06] <geser> then you don't need to go through REVU again
[12:07] <falktx> - thanks -
[12:07] <falktx> so how?
[12:07] <geser> create a debdiff with your changes (or alternatively prepare a bzr branch for merging (if you like))
[12:08] <geser> open a bug and attach your debdiff (or link merge proposal) to the bug and subscribe ubuntu-universe-sponsors for sponsoring
[12:08] <geser> see also https://wiki.ubuntu.com/SponsorshipProcess
[12:09] <falktx> i'll look into that, thanks again
[12:10] <porthose>  it may need a FFe https://wiki.ubuntu.com/FreezeExceptionProcess
[12:11] <geser> not for a fix of a bug
[12:11] <porthose> key word *may* :)
[12:15] <falktx> thanks guys, you rock!
[12:15] <falktx> I created a debdiff, now into sponsorship...
[12:28] <falktx> I'm unsure about what to do next...
[12:28] <falktx> https://bugs.launchpad.net/ubuntu/+source/zyn/+bug/532590
[12:34] <falktx> should I just wait ? or is it something missing ?
[12:46] <randomaction> falktx: I mean, subscribe the team to your bug
[12:47] <randomaction> there's a "Subscribe someone else" link on the right-hand side
[12:51] <falktx> done
[12:51] <falktx> thanks
[13:12] <JamieBennett> I'm trying to push a revision of a package up to REVU: http://revu.ubuntuwire.com/p/webservice-office-zoho but its not appearing even though I get a successful upload message. I pushed around an hour ago and still nothing. Any idea's (I signed the package with a different key this time, would that cause problems?)
[13:16] <mok0> JamieBennett: If it's a revision, better do through a bug in LP.
[13:16] <mok0> JamieBennett: because it needs to clear through as an SRU anyway
[13:17] <JamieBennett> mok0: sorry, its me not being clear, this is a new package but I made changes to it today and tried to upload
[13:17] <mok0> JamieBennett: ah
[13:17] <JamieBennett> Its currently not in the archive
[13:18] <mok0> JamieBennett: the signing key must be the same as the one you have in LP
[13:18] <JamieBennett> mok0: Oh, maybe thats it, I'm not sure if LP has this new key
[13:18]  * JamieBennett goes to check
[13:23] <c_korn> hello. the scilab package in lucid is currently broken because the build for amd64 timed out. I added a watchdog process which prints a message every ten minutes (because the compilation just needs some time but it is still going on). do I need a FFe for this change ?
[13:23] <c_korn> (would be a new revision to sync from Debian)
[13:24] <mok0> c_korn: yes you would
[13:24] <geser> mok0: why a FFe?
[13:25] <mok0> c_korn: because there are new features in a new version
[13:25] <geser> mok0: is only a revision bump, no upstream version bump if I understood c_korn correctly
[13:25] <mok0> ah
[13:25] <c_korn> new features ? I already got a FFe granted for scilab 5.2.1-3 the new one is 5.2.1-4 which adds the watchdog
[13:26] <c_korn> yes, geser is right
[13:26] <mok0> But you need to file a sync request then
[13:27] <c_korn> yeah, I just talked to the Debian maintainer. he is currently building it. so I have to wait for the package to be in Debian.
[13:27] <c_korn> I thank you
[13:28] <mok0> c_korn: I remember scilab 5.1 had lots of problems compiling etc. Is that better now?
[13:28] <mok0> c_korn: I helped push a bunch of dependencies through AFAIR
[13:30] <c_korn> yeah, we required a lot of packages synced from Debian last time. and because we were a bit late we also required a FFe for them. should be easier this time. it already compiled fine in a PPA. just times out on amd64 when building for the archive.
[13:30] <mok0> c_korn: what do you mean "times out"?
[13:31] <geser> mok0: if there is no output for 150min the build gets killed
[13:31] <mok0> Weird
[13:31] <mok0> What is it waiting for?
[13:31] <c_korn> yeah, and the compilation of the docs is "slow like hell" :)
[13:32] <c_korn> mok0: it is not waiting. it is compiling. it is java :)
[13:32] <geser> either the build is bugged or a very long running process (which is it in this case)
[13:33] <c_korn> it just takes some time. 4h in a PPA: https://launchpad.net/~getdeb-package-managers/+archive/ppa/+build/1527822
[13:33] <c_korn> the build for the archive times out after 3h: https://launchpad.net/ubuntu/+source/scilab/5.2.1-3/+build/1525155
[13:38] <StevenK> The PPA builds are slightly faster, I think
[13:39] <geser> btw: does somebody know if ghc6 on armel is still building (for over a week now) or stuck?
[13:41] <lan3y> probably stuck :(
[13:41] <lan3y> wait what is this nick
[13:41] <ogra> its unlikely that you have packages that build a week ... even on armel
[13:42] <Laney> it took 6 days on debian
[13:43] <Laney> but yeah i would expect it to have done by now
[13:47] <ogra> Laney, what kind of armel builders does debian use ? we have 800MHz/512MB machines
[13:47] <ogra> ubuntu builds should be generally a bit faster than debian ones
[13:49] <Laney> ogra: http://db.debian.org/machines.cgi?host=ancina http://db.debian.org/machines.cgi?host=arcadelt http://db.debian.org/machines.cgi?host=argento
[13:50] <Laney> there must be some other difference that makes the build hang on Ubuntu but not Debian :(
[13:50] <ogra> debian doesnt optimize for ARMv7
[13:51] <ogra> we use v7 and thumb2 optimizations
[13:51] <ogra> sad there is no cpuspeed info on the pages
[13:53] <Laney> you could check in #debian-arm
[13:58] <bjsnider> siretart, you're the ffmpeg expert, not me, but isn't the 0.5.1 code actually older than what is in karmic?
[14:02] <JamieBennett> still no luck with REVU. I've added my key to launchpad, is there a delay before it works with REVU?
[14:10] <JamieBennett> are there any admins around to poke REVU and see whats happening for me?
[14:11] <mok0> JamieBennett: All I can see is that you have a rejected upload at 15:01
[14:12] <JamieBennett> mok0: does it say why it was rejected?
[14:12] <mok0> No
[14:13] <mok0> JamieBennett: Nothing I know about, anyway
[14:13] <mok0> But it very likely has to do with your gpg key changes
[14:14] <JamieBennett> mok0: Shame, I'm getting a 'Successfully uploaded packages.' message. Maybe its a key propogation problem, my key is in launchpad, maybe there is some delay?
[14:14] <mok0> JamieBennett: Indeed there is
[14:15] <JamieBennett> mok0: OK, I'll leave it for a while, thanks for the help so far.
[14:15] <mok0> JamieBennett: NP
[14:15] <JamieBennett> and as that is said, the package magically appears this time :)
[14:16] <ogra> :)
[14:17] <mok0> Ah, patience is a virtue
[14:17] <JamieBennett> mok0: bah
[14:17] <JamieBennett> ;)
[14:17] <mok0> That said, can anyone tell me why I'm getting two different popup notification every time?
[14:17] <mok0> Because it annoys the hell out of me...
[14:18] <JamieBennett> ls
[14:18]  * JamieBennett is having one of them days
[14:18] <mok0> No files found
[15:15] <hakaishi> Hi everyone! Could someone tell me how a package from Debian gets into the Ubuntu sources?
[15:17] <hggdh> usually it is via a sync request
[15:23] <hakaishi> hggdh: and where could I do that?
[15:25] <hggdh> hakaishi: please see https://wiki.ubuntu.com/SyncRequestProcess
[15:25] <hakaishi> cool, thank you
[15:26] <mok0> hakaishi: bear in mind that we are now in FF, and syncs will only happen if they fix bugs
[15:26] <nigelb> hakaishi: if its something for lucid, please see https://wiki.ubuntu.com/FreezeExceptionProcess too
[15:28] <hakaishi> Since my packages only got uploaded to debian, it'll take some time till I can do a sync request...
[15:32] <donkyhotay> can someone help me figure out why my package isn't showing up in revu? I followed the instructions at https://wiki.ubuntu.com/MOTU/Packages/REVU including logging in, uploading GPG key and using dput. Didn't get any errors or messages but it hasn't shown up yet.
[15:37] <hakaishi> donkyhotay: did you get an e-mail for successfully uploading? - If not it would be something wrong with your dput.cf
[15:39] <donkyhotay> I didn't get a confirmation Email, I didn't change my dput.cf since it sounded like the default file on a standard karmic would work so long as I used "dput revu filename_source.changes" which I did
[15:41] <hakaishi> donkyhotay: please look at https://wiki.ubuntu.com/MOTU/Packages/REVU
[15:43] <donkyhotay> As I mentioned before, I followed the instructions on that page. I even checked my dput.cf file and confirmed it has the revu entry the wiki says is preconfigured from 6.06 and on
[15:46] <hakaishi> donkyhotay: and dput did the upload without any warnings/errors? - That's strange... Then I don't know how to help you, sorry  -.-'
[15:47] <donkyhotay> Yeah, thats the part that confuses me. I did everything exactly, dput gave me no warnings or errors. Confirmed my key was uploaded, even redid the package to confirm dpkg-buildpackage wasn't giving my warnings of this being unsigned (which I did get earlier but have since resolved)
[15:49] <hakaishi> mok0: From which Debian version will the packages be included into the new Ubuntu version? (I'll have to do the sync request till the next DebianImportFreeze, right?) - Will it be sid, or squeeze?
[15:50] <mok0> hakaishi: for lucid, it is testing
[15:50] <mok0> hakaishi: normally, it's unstable
[15:50] <mok0> (Lucid is a LTS release)
[15:51] <mok0> hakaishi: So for lucid+1, the sync will be from unstable. It will get synced automatically when the cycle starts
[15:51] <mok0> hakaishi: therefore, if the sync you request is for lucid+1, there's no need to do anything
[15:52] <hakaishi> mok0: okay, thank you for your help^^
[15:52] <mok0> hakaishi: my pleasure .-)
[15:52] <donkyhotay> Oh wait... my old key is the one currently registered? I thought I checked that... Well I feel a little silly now. I think I found the problem.
[15:53] <hakaishi> donkyhotay: then I'll wish you goog luck ;)
[15:53] <hakaishi> *good
[15:54] <donkyhotay> I'm updating my keys, should work this time around.
[15:56] <hakaishi> mok0: There is still one more thing I'm wondering about. If my packages from sid get into lucid+1, will I have to upload them into sid+1 to get the packages into lucid+2 again?
[15:57] <mok0> hakaishi: once the package is in Debian, it will be synced for every Ubuntu release
[15:57] <mok0> hakaishi: so if you maintain your package in Debian (sid) all is dandy
[15:57] <hakaishi> mok0: cool XD, thanks again^^
[15:59] <hakaishi> bye bye ;)
[16:09] <hyperair> any archive admin around?
[16:09] <hyperair> bug #529340 could use some love
[16:14] <lightnin> Is there a debhelper script that installs / registers .desktop files?
[16:15] <lightnin> or do I just use dh_install desktop_file /usr/share/applications?
[16:20] <hyperair> lightnin: the latter.
[16:21] <hyperair> lightnin: a dpkg trigger from one of the packages will register it.
[16:21] <sebner> lightnin: you might want to use a .install file though
[16:22] <lightnin> hyperair:Thanks! How do I go about making a "dpkg trigger" happen?
[16:28] <hyperair> lightnin: just put the file in /usr/share/applications, it'll trigger automatically.
[16:29] <donkyhotay> Yep, outdated GPG key was definitely my problem as my package is now on revu. Now I just need to wait for some MOTU's to check out my game and either advocate it or tell me whats wrong with. (c:
[16:29] <vincs> Hi.
[16:30] <lightnin> cool. Do I  need to run "gtk-update-icon-cache"? It's in my postinst script, but it seems like it's not needed if I've installed the desktop file (and it breaks in KDE)
[16:30] <hyperair> i'm not sure
[16:31] <vincs> When debian/watch file is used, do a get-orig-source rule is needed in debian/rules file ?
[16:35] <sebner> hyperair: will you wait for banshee 1.5.5 until updating?
[16:36] <hyperair> sebner: i'm waiting for taglib-sharp. our archive-admins are asleep, i think?
[16:36] <hyperair> sebner: at the rate we're going, it's better to wait for 1.5.5, yeah.
[16:36] <hyperair> sebner: assuming taglib-sharp gets in before 1.5.5 appears.
[16:37] <sebner> hyperair: I guess, it's nearly weekend after all.  Or you bug the archive admin which is on duty today
[16:39] <hyperair> sebner: who?
[16:39] <hyperair> sebner: (and the facebook video is pretty funny all the same, if you feel like viewing it)
[16:39] <sebner> hyperair: jdstrand
[16:39] <hyperair> sebner: how do you tell?
[16:39] <sebner> hyperair: nvm, I'm not at facebook
[16:40] <hyperair> heheh
[16:40] <sebner> hyperair: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
[16:40] <hyperair> ah cool
[16:48] <lightnin> Should I use dh_installmime to install xml files describing new mimetypes? Seems like it must be in /debian directory for this to work, but mimetype .xml file is in upstream tarball...
[16:50] <vincs> When debian/watch file is used, do a get-orig-source rule is needed in debian/rules file ?
[16:56] <randomaction> vincs: it's a good idea if there's no tarball that corresponds to the current state of the package (e.g. it's a snapshot or it was repackaged)
[16:57] <vincs> It is a new package (not in debian or ubuntu).
[16:58] <vincs> But the tarball is in upstream.
[16:58] <randomaction> if the tarball for the version you're packaging can be obtained from upstream, there's no need for get-orig-source rule
[17:00] <vincs> Ok. Thanks for your reply.
[17:04] <hyperair> lightnin: the stuff in /usr/share/mime is debian-specific
[17:05] <lightnin> hyperair: Oh, ok, so it doesn't really need to be in upstream tarball. I guess it doesn't hurt to be there though. (Btw- I am upstream and packager...)
[17:07] <mok0> hyperair: can you help me out?
[17:08] <hyperair> mok0: what's up?
[17:08] <mok0> hyperair: bug 489845
[17:09] <mok0> hyperair: What version is in lucid?
[17:10] <hyperair>   codelite | 1.0.2893+dfsg-0ubuntu2 | karmic/universe | source, amd64, i386
[17:10] <hyperair>   codelite | <IP_ADDRESS>81+dfsg-0ubuntu1 | lucid/universe | source, amd64, i386
[17:10] <mok0> yes just got that
[17:11] <mok0> hyperair: is it relevant to backport it?
[17:11] <hyperair> mok0: i suppose so. there weren't many packaging changes. i think it can be ported directly.
[17:11] <hyperair> mok0: i haven't testbuilt it though
[17:11] <mok0> hyperair: I can do that
[17:12] <mok0> hyperair: don't think it will be a problem, there aren't many toolchain changes
[17:12] <hyperair> mok0: please do, then. i have to drag my ass out the door (and walk back to my hostel) pretty soon =)
[17:12] <mok0> hyperair: right, thnx
[17:12] <mok0> See you
[17:13] <hyperair> mok0: not yet, but soon enough that i can't finish a testbuild ;-)
[17:13] <hyperair> mok0: i own a pretty modest dual core machine, see
[17:13] <mok0> hyperair: don't I know it? It takes forever...
[17:13] <mok0> :)
[17:14] <jdong> lol I just found out to my dismay that this new cluster I have access to is a lie.
[17:14] <hyperair> mok0: yep. it was the first compilation that managed to overheat and shutdown my notebook =p
[17:14] <jdong> it claims to be octo 3.06 xeon with 24G of RAM
[17:14] <jdong> but apparently is all running virtualized.
[17:14] <mok0> hyperair: great package to choose for maintenance, then ;-)
[17:14] <jdong> was kinda surprised when python took longer to ./configure there than build locally.
[17:15] <mok0> jdong: hehe
[17:15] <hyperair> mok0: hehehe. i learnt my ^Z trick then ;-)
[17:15] <jdong> hyperair: haha I have a script called heatlimit.py here
[17:15] <jdong> that monitors ACPI thermal zones and throttles tasks based on temp.
[17:15] <hyperair> jdong: that's made of win. =p
[17:16] <jdong> stupid laptops.
[17:16] <jdong> :)
[17:16] <hyperair> jdong: i went the phc way.
[17:16] <hyperair> jdong: undervolted my CPU, and cut the temperature by 20 degrees celcius =p
[17:16] <jdong> I should just open up the stupid thing and blow it out with some compressed air
[17:16] <jdong> it's just dust clogging up the fan.
[17:16] <jdong> too lazy.
[17:16] <hyperair> oh that's your case eh?
[17:16] <hyperair> my fan is clean.
[17:17] <hyperair> it overheats anyway
[17:17] <jdong> ah ,ouch
[17:17] <hyperair> overheated*
[17:17] <hyperair> and the stupid thing is that it never generates enough heat when i want it to.
[17:17] <hyperair> i was feeling particularly cold in this air-conditioned room earlier, and started a kernel compilation, turned off phc, and it didn't go past 60 degrees.
[17:18] <jdong> hahaha
[17:18]  * hyperair sighs
[17:18] <jdong> one of my friends keeps a quad-core P4 Xeon in his room for that purpose.
[17:18] <hyperair> heheheh
[17:18] <jdong> he's told me that he tripped a circuit breaker with folding@home once.
[17:18] <jdong> whoops bet that didn't help with heating :)
[17:18] <hyperair> heheheh
[17:18] <hyperair> yeah, i can imagine
[17:20] <lightnin> Hmm... I don't seem to be able to make my binary package register it's new mime filetype on the target system. dh_installmime doesn't seem to do it...
[17:28] <sebner> hyperair: syncs are processed in some hours so we might be lucky ones just before weekend ;D
[17:29] <hyperair> sebner: cool
[17:39] <vincs> I have reupload my fisrt package in REVU. REVU shows now no warning or common error. Do new packages are processed in a certain order or do I need to ask for an first person to advocate ?
[17:41] <ScottK> vincs: We are past feature freeze for Lucid, so reviewing new packages is a low priority at the moment.
[17:44] <vincs> ScottK: I know but as I am new at packaging and I would like to upload 4 packages for lucid+1. I start early.
[17:48] <ScottK> OK, as long as your expectations aren't high ....
[17:51] <vincs> No. If someone comments my package early I will make the necessary  changes. If not, I will wait.
[18:39] <lightnin> If I need to run update-mime-database after registering a new filetype for my application, should I declare it as a dependency? It doesn't seem to come with kubuntu...
[18:48] <randomaction> yes
[18:49] <randomaction> you can use dh_installmime, which adds necessary fragments to maintainer scripts and adds necessary packages to ${misc:Depends}
[19:29] <funkyHat> I've attached a compiled .deb for sensors-applet 2.2.5-3 to https://bugs.edge.launchpad.net/ubuntu/+source/sensors-applet/+bug/380669
[19:29] <funkyHat> Don't know if that is a normal thing to do but it was suggest I find testers for the new version.
[19:30] <funkyHat> I suppose a 32bit version would probably be helpful too
[19:54] <siretart> bjsnider: no, but how do you come to this opinion?
[20:06] <bjsnider> siretart, i tried building the 0.5.1 release in pbuilder using the build scripts for the karmic ffmpeg. the result failed because the vhook stuff was still there. but the build scripts do not contain the --disable-vhook flag, and the reason is that the vhook code isn't in the karmic version. i then explicitly asked the ffmpeg devs in that channel when vhook was removed from the code and they gave me an exact date: march 3 2009. i then asked if the
[20:06] <bjsnider>  rest of the 5.1 release is at least that old and the answer was: yes.
[20:08] <superm1> siretart, are you aware that mplayer FTBFS right now?
[20:08] <siretart> superm1: no, but I'm aware that I really should revisit and finally upload the local changes to the package I have on my laptop
[20:09] <superm1> siretart, indeed :)  I was considering looking into the FTBFS but figured its better to check with you first and not trump what you might have going on
[20:10] <siretart> superm1: anyways, why does it ftbfs?
[20:10] <bjsnider> it pulls in nvidia-current because of the build-depends on nvidia-xxx-libvdpau
[20:10] <siretart> bjsnider: the version between the version in karmic and 0.5.1 should be pretty close. the difference is mainly that many patches that were in karmic got committed upstream for 0.5.1
[20:10] <superm1> siretart, libmp4codec/ve_264.c or something like that (i dont have the log handy)
[20:10] <bjsnider> easy to fix
[20:11] <mok0> jdong: ping
[20:11] <bjsnider> siretart, i just downloaded the tarball. maybe i got older code
[20:13] <siretart> bjsnider: check the diffstat: http://wiki.tauware.de/~siretart/ffmpeg/diffstat.txt
[20:16] <bjsnider> siretart, but your version doesn't have the two soname changes int he recent code
[20:16] <bjsnider> and also, they told me there's a .6 release coming this month
[20:16] <bjsnider> i guess that isn't enough time to get it into lucid
[20:17] <sistpoty> no
[20:17] <siretart> bjsnider: or you can check the diff here: http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=shortlog;h=refs/heads/upstream-0.5
[20:18]  * sebner waves as sistpoty :D
[20:18] <siretart> bjsnider: no, 0.5.1 does not introduce any soname change. We need versioned symbols deployed before we can do that
[20:18] <sistpoty> huhu sebner
[20:18] <siretart> hey sistpoty!
[20:18] <sistpoty> hi siretart
[20:18] <sebner> sistpoty: In 4 Tagen hab ich Grunzüge der Informatik Wiederholungsprüfung. Wäre recht mal anfang zu lernen xD
[20:19] <sistpoty> sebner: better do that than ;)
[20:19] <sistpoty> then even
[20:19] <sebner> sistpoty: b000000000000ring :P
[20:20] <sistpoty> heh
[20:22] <siretart> sebner: 2nd or 3rd try?
[20:22] <bjsnider> siretart, did you have to explicitly disable vhook in the 5.1 build?
[20:23] <sebner> siretart: 2nd or course :P well, if I'm that lazy again it might turn out in a 3rd one xD
[20:25] <siretart> bjsnider: vhook is disabled since ffmpeg-debian_0.svn20080925-1
[20:25] <siretart> bjsnider: so that's no change since karmic AFAIUI
[20:25] <bjsnider> i couldn't find that build flag in the confflags file or the rues file
[20:27] <sebner> siretart: unless you wanna give me a hand :P
[20:27] <siretart> bjsnider: debian/confflags, line 75
[20:29] <bjsnider> strange
[20:29] <siretart> don't horrify me like that
[20:29] <siretart> ;-)
[20:30] <bjsnider> it's not in these build scripts i'm using
[20:30] <bjsnider> where did i get them
[20:34]  * siretart points bjsnider to http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=summary
[21:02] <blueyed> "bzr branch lp:ubuntu/apport" does not result in the current sources. By design?
[21:07] <geser> probably an error during package import into bzr
[21:09] <geser> yep, see http://package-import.ubuntu.com/status/apport.html#2010-02-22%2011:47:45.304032
[21:10] <jpds> lolsiretart .
[21:25] <siretart> jpds?
[21:25] <jpds> siretart: See log above. ;)
[21:26] <siretart> oh, seems I'm holding some lock :-)
[21:26]  * siretart passes a lock to jpds
[21:26]  * jpds hugs siretart.
[21:27] <siretart> :-)
[21:36] <blueyed> oh.. is there no more reasonable automatic timeout?
[21:39] <james_w> blueyed: you want lp:apport for the moment
[21:39] <blueyed> james_w: thanks, I've used the line from "apt-get source apport" already.
[21:41] <sebner> christoph_debian: persia: I'm going too FFe sync supertux, are you ok with that? (Uhm, I already filed the bug though ^^)
[21:42] <persia> sebner: Always.  Except where freezes get in the way, the Games Team likes to be in sync.
[21:42] <sebner> persia: Great :)
[21:58] <sebner> persia: haha, new record for me. 16 minutes until FFe granted and archive admins subscribed :D
[21:59] <persia> sebner: Clearly you have some work to do.
[21:59] <sebner> persia: hmm? rationale, changelog, buildlog, installing + screenshot all done
[22:00] <persia> sebner: You might want to start digging into RCbugs.  At this point none of them need FFes, but once the freeze gets firmer, we end up needing release approval for every upload.  Building a background in RCBug work should get your turnaround time down to a minute or two once we get there.
[22:00] <persia> sebner: The work is on reducing the 16 minutes, not on that bug :)
[22:01] <sebner> persia: ah sure, but I might wait until next week (some important exam on tuesday and still a lot to learn)
[22:01] <persia> Of course.  $study (like $life and $work) must necessarily take priority over Ubuntu, else you'll burn out and be unable to help.
[22:03] <sebner> persia: heh, I have to defend myself. Building supertux took surely ~5-10 minutes :P
[22:05] <sebner> persia: http://qa.ubuntuwire.com/bugs/rcbugs/ is still the place to start right?
[22:06] <persia> sebner: If that's not the place to start, complain loudly.
[22:07] <persia> sebner: If something is wrong, the most likely thing would be that it's still targeting karmic, but that usually changes around DIF time
[22:07] <christoph_debian> sebner: was going to ask for it myself
[22:08] <sebner> christoph_debian: heh, done already :)
[22:08] <sebner> persia: aye :)
[22:08] <sistpoty> thanks christoph_debian for packaging it in the first place :)
[22:08] <christoph_debian> :)
[22:08]  * sebner ^5 christoph_debian
[22:18] <sistpoty> superm1: I'm inclined to accept the FFe for bug #532933, any objections from your side?
[22:22] <micahg> how do I force a build with a non-ubuntu maintainer address to build?
[22:23] <persia> Easiest way is to use an unmangled dpkg-buildpackage
[22:23] <micahg> persia: for upload...
[22:23] <persia> You can also fiddle with dpkg-source
[22:23] <micahg> sorry, I meant source build for upload
[22:23] <persia> Yes.
[22:23] <jdong> micahg: unset DEBMAIL?
[22:23] <jdong> DEBEMAIL?
[22:24] <persia> micahg: So, what's the top line of the changelog, and what's the maintainer?
[22:24] <micahg> persia: it's for a no source change rebuild of openJDK
[22:24] <micahg> to PPA
[22:24] <persia> micahg: So, what's the top line of the changelog, and what's the maintainer?
[22:25] <micahg> persia: not what they should be...
[22:25] <persia> There is no "should"
[22:25] <superm1> sistpoty, not that i can think of
[22:25] <persia> So, I'll help you with the tools.
[22:25] <persia> I won't help you get it into a PPA.
[22:25] <micahg> ubuntux and not an ubuntu.com address
[22:25] <sistpoty> superm1: thanks!
[22:25] <persia> With luck, the former will result in the latter.
[22:26] <micahg> I normally do debuild -S -sd, but that obviously doesn't work
[22:26] <micahg> let me ask him if there's a reason that he doesn't update the maintainter for Ubuntu
[22:27] <micahg> not around...
[22:27] <persia> micahg: The easiest way is to use an unmangled dpkg-buildpackge.  You can also  fiddle with dpkg-source if you won't want to backport.  If you give me the top line of the changelog and the Maintainer entry, I may be able to suggest something else.
[22:27] <sistpoty> superm1: another question: would you volunteer as delegate for mythbuntu packages in universe for ubuntu-release again? or would you suggest someone else=
[22:27] <jdong> micahg: as mentioned, if the DEBMAIL environment variable is blank, the maintainer check isn't done.
[22:27] <sistpoty> s/=/?
[22:27] <micahg> jdong: k, I'll just do taht
[22:27] <persia> jdong: That's not actually the case, depending on the changelog entries.
[22:27] <jdong> micahg: DEBEMAIL rather
[22:27] <jdong> with the E.
[22:27] <jdong> persia: oh?
[22:27] <micahg> this is still unofficial and I don't want to fiddle too much
[22:28] <superm1> siretart`, i'm still the one that sponsors for all of ~mythbuntu (none of them have gotten motu or ~mythbuntu-dev yet, so yes, i'm fine)
[22:28] <persia> jdong: At least I almost never set DEBEMAIL, and I get the check.
[22:28] <micahg> persia: openjdk-6 (6b18~pre1-1ubuntu1.0ffox36.1) lucid; urgency=low
[22:28] <sistpoty> superm1: thanks!
[22:28] <micahg> jdong: no go
[22:28] <persia> micahg: OK.  The issue you're encountering is that you have "ubuntu" in the version.  Don't do that.
[22:29] <micahg> persia: that's what the current revision has.
[22:29] <jdong> "  - scripts/dpkg-source.pl: Check that debian/control complies with
[22:29] <jdong>     https://wiki.ubuntu.com/DebianMaintainerField: If $DEBEMAIL contains
[22:29] <jdong><EMAIL_ADDRESS>refuse to build a source package if we have an Ubuntu
[22:29] <jdong>     version number, but Maintainer: is not an Ubuntu address. Output a
[22:29] <jdong>     warning if $DEBEMAIL contains 'ubuntu' but not<EMAIL_ADDRESS>or if
[22:29] <jdong>     there is no XSBC-Original-Maintainer: field for packages with an
[22:29] <jdong> gah
[22:29] <micahg> it is currently ubuntu1 and it built for him
[22:29] <jdong> that was a nastty paste
[22:29] <micahg> so I'm just wondering what switch I need to override
[22:30] <jdong> it doesn't appear to have a switch to bypass the check.
[22:31] <geser> unset $DEBEMAIL temporarily
[22:32] <persia> This whole "let's support third-party repositories" thing probably needs some tools work.
[22:33] <jdong> geser: that's what I said initially, and it seems like it didn't work
[22:36] <sistpoty> asac: would you be willing to act as ubuntu-release delegate again for universe packages related to mozilla packages?
[22:36]  * micahg gives up and updates maintainer
[22:37] <vincs> I have upload my first package to REVU. I am looking for someone to comment it. I have already amend all common errors. I understand that it is not the right time for packaging so I won't be upset if no one answers the call.
[22:39] <sistpoty> cody-somerville: would you volunteer as ubuntu-release delegate for universe packages of xubuntu again?
[22:39] <persia> micahg: Aren't you the primary mozillateam maintainer these days?
[22:40] <micahg> persia: I wouldn't exactly say that...but I am one of the maintainers
[22:40] <cody-somerville> sistpoty, Provided mr_pouit is permitted to also volunteer, yes :)
[22:40] <sistpoty> cody-somerville: sure, if you can convince him ;)
[22:40] <micahg> persia: but I don't have upload rights
[22:40] <micahg> yet
[22:40]  * persia thinks we should have a single release delegate for each delegation to preserve a small well-knit release team
[22:40] <persia> micahg: Ah.  Nevermind then :)
[22:41] <sistpoty> micahg, persia: yes, I'm trying to be a little bit conservative, but I guess a fallback might come in handy though
[22:41]  * micahg will probably be pushing through most of the changes to mozilla universe packages in any case
[22:42] <sistpoty> persia: redundancy eliminates a single point of ... blocking ;)
[22:42] <sistpoty> micahg: would you want to volunteer for the position?
[22:43] <micahg> sistpoty: do I need upload rights?
[22:43] <sistpoty> micahg: you'll mainly need to know if a proposed FFe is good, so not necessarily
[22:44] <persia> sistpoty: Well, yes, but I'd hope the redundancy could be found elsewhere within the release team.  Maybe I'm optimistic.
[22:45] <sistpoty> persia: we've used more than one delegate for a package set in the past, the results were usually good
[22:46] <micahg> sistpoty: I just don't know if I have the time...in fact this cycle it's probably not a good idea, but maybe next cycle
[22:48] <sistpoty> micahg: ok, fair call. I'll treat you as fallback, if that's ok, and just ask you (either on irc, or via bug-report subscription) for input in case of mozilla-related package updates, ok?
[22:49] <micahg> sistpoty: sure, that's fine
[22:49] <sistpoty> :)
[22:49] <micahg> thanks
[22:50] <sistpoty> persia: I've no clue about netbook and edubuntu atm, do you have some suggestions? should we drop one of these for delegation?
[22:50] <sistpoty> (or anyone else of course)
[22:51] <persia> For edubuntu I'd probably target highvoltage or stgraber
[22:51] <persia> Netbook and Desktop seem to be merging: I'd suggest seb128 or didrocks for netbook.
[22:51] <sistpoty> highvoltage, stgraber: would you volunteer for edubuntu as ubuntu-release delegate for universe packages?=
[22:52] <sistpoty> persia: thanks!
[22:52] <persia> sistpoty: Out of curiosity, why just for universe packages?
[22:53] <persia> sistpoty: More pointedly, I don't think Netbook has anything left in universe, and edubuntu has precious little (plus the edubuntu team is before the TB requesting a packageset currently)
[22:53] <sistpoty> persia: basically based on slangasek's mail.
[22:54] <sistpoty> persia: I guess main packages have a high overlap so ubuntu-release should take care
[22:54]  * persia hopes that ArchiveReorg/components can follow closely now that ArchiveReorg/permissions is essentially complete
[22:55] <persia> sistpoty: My issue is that the set of people caring for a package doesn't typically differ just because a package happens to be in one component or another, given the new permissions structure.
[22:55] <persia> For example, the CLI/Mono team handles stuff in both main and universe.
[22:55] <persia> as does MozillaTeam
[22:56] <persia> For some stuff, it matters.  For example, some Xubuntu stuff is part of the core set, so shouldn't be delegated.  But I don't understand the point for stuff in main that isn't in core.
[22:57] <sistpoty> persia: CLI/Mono does have lots of rdepends in other seeds, at least I believe so. Hence there needs to be a central point of syncrhonisation
[22:57] <persia> sistpoty: Sure, but that's completely separate from main/universe
[22:58] <persia> http://people.canonical.com/~cjwatson/packagesets is a handy resource
[22:58] <sistpoty> persia: I guess delegations might be better thought of as packages seeded only by one team
[22:58] <persia> Yes :)
[22:58] <persia> Or rather, within one packageset
[22:59] <sistpoty> whatever it's called :=
[22:59] <sistpoty> :)
[22:59] <persia> (some packagesets, like CLI/Mono are not generated from a seed currently)
[22:59] <persia> This probably matters most to the edubuntu folk, as they have lots of stuff that is only in their packageset yet happens to be in main.
[23:00] <sistpoty> persia: I guess the main rationale is that a package (atm) is currently easily visibe to fall under main or universe
[23:00] <persia> That's why I pointed you at the packagesets output list.
[23:00] <persia> That makes it more easy to figure out which packageset(s) apply.
[23:00] <sistpoty> persia: yes, but everyone involved must know this by hart, so I'd rather suggest to go step by step
[23:01] <persia> Well, OK.
[23:01] <stgraber> sistpoty: it'd make sense for both of us to do that yes
[23:01] <persia> But for next release, can we please use packagesets, even if components still exist?
[23:01] <sistpoty> stgraber: thanks!
[23:02] <sistpoty> persia: I don't object to this.
[23:03] <sistpoty> persia: at least in the hope that the main<->universe merge of release-teams will have settled during lucid (still biting a little bit at it)
[23:03] <persia> sistpoty: If you happen to move from there to "I support this" in the next 5 months, I'll be happy, but I'll also take it to others.
[23:03] <persia> sistpoty: Oh!  Yeah, if that's still not smooth, then I agree it doesn't make sense to add more complexity now.
[23:04] <sistpoty> persia: well, give it some time, everyone is still adjusting to it ;)
[23:04] <sistpoty> (it's neither rough, nor smooth, it just takes some time so that everyone is aware of it)
[23:06] <persia> Understood.
[23:21] <asac> sistpoty: yeah.
[23:21] <sistpoty> thanks asac!
[23:21] <asac> welcome
[23:22] <LLStarks> hi. what are the chances of a tiny bugfixing debdiff being accepted for gstreamer -bad a day or two after tonight's release?
[23:27] <sistpoty> LLStarks: bugfix only debdiffs aren't subject to feature freez
[23:27] <sistpoty> +e
[23:28] <LLStarks> what would be subject to freeze rules?
[23:28] <sistpoty> LLStarks: anything that introduces new features
[23:28] <LLStarks> define "features"
[23:29] <slangasek> persia: the set of people caring about the packages doesn't differ, but my willingness to wholesale delegate the freeze decisions does
[23:29] <LLStarks> nvm.
[23:29] <sistpoty> LLStarks: that's difficult. anything that fixes a bug isn't a feature ;)
[23:29] <persia> slangasek: OK.  What would it take to change that willingness?  That feels like something leftover for resolution to make components go away.
[23:29] <sistpoty> LLStarks: if in doubt, just file a FFe, it'll get sorted
[23:30] <slangasek> persia: it's really about components as a proxy for seeds, for me
[23:30] <slangasek> persia: I would still not want to delegate decisions about packages seeded on the Ubuntu CDs
[23:30] <LLStarks> so, if blah 0.0.1 comes out tonight but bugfix just  misses the upstream deadline but is accepted to the git, 0.0.1-ubuntu1 or 0.0.1-1 would be allowed to fix it ahead of an upstream release?
[23:31] <sistpoty> slangasek: actually I would, if the team is responsible for the image in question (and the package doesn't influence any other CD)
[23:31] <persia> slangasek: OK, so your issue is mostly that we only have the one report about packagesets, and you need better tools?
[23:31] <sistpoty> is *solely* probably
[23:33] <LLStarks> also, is an ffe more likely to be attended to faster than a simple a bug report that contains a patch/debdiff?
[23:33] <slangasek> persia: which report are you referring to?  I'm not concerned about reporting for my own sake, I just don't know that there's a very clear way to communicate to delegates what's being delegated to them at present if we describe it in terms of seeds
[23:33] <sistpoty> persia: btw.: ok with my interpretation: http://paste.ubuntu.com/389257/
[23:34] <sistpoty> *nod* slangasek
[23:35] <slangasek> LLStarks: if a bug requires a feature freeze exception, it needs to be touched by *both* the release team and a sponsor, which are normally separate roles, so... no
[23:36] <persia> slangasek: http://people.canonical.com/~cjwatson/packagesets
[23:37] <persia> sistpoty: Yes.  I'm seeking someone for studio, but probably not until the next release cycle.  I strongly recommend didrocks also for Netbook.  The final paragraph seems sane to me.
[23:38] <sistpoty> persia: you could volunteer for -studio though ;)
[23:39] <sistpoty> persia: thanks for proofreading though :)
[23:39] <persia> sistpoty: I'm not convinced I'd be a good delegate.  There are reasons I haven't volunteered for the release team previously.
[23:39] <sistpoty> heh
[23:39] <slangasek> persia: so by packageset, the ones I would not want to delegate are: core, desktop-core, langpack (well - delegate it to pitti, same thing), mobile, ubuntu-desktop, ubuntu-server, unr
[23:40] <persia> slangasek: Why only those?  Why not to arbitrary packagesets?
[23:40] <persia> slangasek: nvm  misread.
[23:41] <persia> slangasek: So I think you shouldn't delegate core or desktop-core, or langpack: those are clearly central.  I don't know why you shouldn't delegate to ubuntu-desktop, ubuntu-server, and unr for non-central packages.  If mobile is still there, that's a bug, and I'll try to fix it.
[23:41] <persia> slangasek: That said, I'd hope you'd pick your delegates carefully.
[23:42] <slangasek> persia: and the fact that packages that are in the intersection of sets are listed as being in both package sets makes this report suboptimal, yah
[23:43] <persia> slangasek: So would you be amenable to delegation of anything not in core or desktop-core that wasn't part of an intersection between packagesets?  (note that this is requirements gathering for lucid+1 policy, not for immediate implementation)
[23:47] <slangasek> persia: I think the field of people those decisions could be delegated to for server, unr, desktop is so small that there would inevitably be conflicts of interest and they would properly be referred back to the release team; so I think it's simpler to not delegate in the first place
[23:47] <slangasek> anyone I would see delegating those to is someone who should be on the release team anyway :)
[23:48] <persia> slangasek: given that, would it make sense to expect each packageset maintaining group to contribute a member to the release team if they sought to be involved in release discussions?
[23:48] <persia> (pitti and Riddell being current good examples of such)
[23:49] <slangasek> I'm not sure the requirement holds for arbitrary packagesets
[23:49] <persia> Why not?
[23:50] <slangasek> hmm, trying to think through it
[23:50] <persia> slangasek: Mind you, my only objection is the implication "some packagesets are better than others" for stuff not core or core-desktop.
[23:51] <persia> slangasek: So it makes sense to me to either delegate for everything (else) or not delegate at all, and tell people to get involved in the release team.
[23:51] <slangasek> if a team such as mythbuntu wants to be autonomous in making decisions about their particular packages, but doesn't have anyone who can commit to helping with the release team generally, what do you think is the correct course of action?
[23:52] <slangasek> well, I don't see it as "better than"
[23:52] <persia> I don't either, but believe it to be potentially misconstrued.
[23:53] <persia> Well, how much extra burden is it to participate in the release team generally?
[23:53] <persia> Is it not just reading one more mailing list and one more IRC channel, and attending one more meeting?
[23:54] <Riddell> there's a mailing list?
[23:55] <persia> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-release
[23:56] <slangasek> persia: hum; abstractly, if we're going to expect each member of the release team to be able to represent the whole release team, then there needs to be some shared model for how this works; that model doesn't come from the mailing list and the meetings, and we haven't really made an attempt yet to scale it
[23:56] <slangasek> Riddell: yes, there is :-)
[23:56] <slangasek> (not heavily used)
[23:56] <slangasek> persia: so I think in practice there has to be some committment to actively engage
[23:57] <persia> slangasek: That makes lots of sense.  Would you be willing to think about this for the next few months, and see if you can come up with a model that doesn't depend on components?
[23:57] <slangasek> sure
[23:58] <persia> Because I agree with most of your criticisms, although I also suspect most of the identified delegates will have the same conflict-of-interest issues that you cite for the ones that concern you more.
[23:58] <slangasek> yep
[23:59] <persia> Thanks for digging into this.  Please let me know if I can be of any help.
[23:59] <sistpoty> slangasek: btw, can you whitelist<EMAIL_ADDRESS>for ubuntu-release? (work address), thanks!


[23:03] <chucky_z> hello, I need to add a power_state: entry to a cloud.cfg, but I'm unsure of where to put it.
[23:03] <chucky_z> should it go straight into the cloud.cfg at the bottom, or inside a cloud.cfg.d file?  This is on CentOS 7 specifically


[00:51] <SonikkuAmerica> The Hebrew language pack?
[00:54] <SonikkuAmerica> newb: LXDE menu > System > Language
[00:54] <ianorlin> he left
[00:54] <phillw> SonikkuAmerica: default language packs in lubuntu have been really curtailed; as he did not hang around, i could not ask.... :/
[00:55] <phillw> ianorlin: (00:54:37) phillw: well, possibly if he stuck around for more than 59 seconds.
[00:55] <SonikkuAmerica> I didn't even see his quit message until it was mentioned.
[00:55] <phillw> let's see ...
[00:56] <phillw> !patience
[00:56] <phillw> yup, it is still there
[00:57] <holstein> those freenode webchat sessions can be a little sketchy as well
[00:57] <phillw> Unit193: whilst I know no one ever reads the topic, would you have a look at re-phrasing  it include !ask ?)
[00:57] <phillw> !ask | holstein
[00:57] <SonikkuAmerica> Pretty soon I'll be able to devote more time to the Lubuntu project, say nothing of the fact I don't use it as my main OS :-)
[00:58] <SonikkuAmerica> Although I'll have some hardware to devote to it now
[00:58] <holstein>  !ask is another one that the new user might not be aware of as well
[00:58] <phillw> holstein: it is always a 'battle' for to teach people to wait for a reply; but I'm not going to run on "must reply within 59 seconds" :P
[00:59] <holstein> phillw: hehe.. *quite* likely the case :)
[00:59] <phillw> holstein: hence my asking Unit193 to include it on the topic :)
[01:01] <holstein> phillw: i dont know that that matters either.. you cant account for everything.. and you cant account for, assuming that i could be right, that the user got dropped
[01:01] <SonikkuAmerica> phillw: As far as I am concerned it shouldn't matter whether or not the hamburger packs come as default in Lubuntu, it's just a matter of pulling those packages from the Internet
[01:02] <holstein> all we can do is our best..
[01:02] <SonikkuAmerica> And by hamburger packs I meant the language packs.
[01:04] <Unit193> phillw: You can't put everything in the topic, there just plain isn't room.  We've been over this type of thing before and you agreed it made sense.  It wouldn't have helped anyway.
[01:04] <phillw> SonikkuAmerica: as we are the only flavour left CD sized, Julien has had to trim things. One of those was lang packs. It's a hard choice.... do we go over CD size; or stay within it? I believe he made the correct decision and fully support him for that.
[01:05] <SonikkuAmerica> phillw: Funny you never realize when I'm agreeing with you :-)
[01:05] <phillw> Unit193: put it on the entry message... no one ever reads that either :P
[01:05] <Unit193> !offtopic
[01:06] <SonikkuAmerica> Good call... :-)
[01:06] <phillw> SonikkuAmerica: I know you are; we're just a bit disappointed to lose some of the standard lang packs.... such is life :)
[01:07] <SonikkuAmerica> phillw: And that's the glory of Lubuntu; for being lightweight, you can do more things with it, unlike any of the other flavors (mainly due to needless kludge)
[01:08] <phillw> Unit193: oh, is there no longer an lubuntu offtopic area? :'(
[01:08] <SonikkuAmerica> Furthermore it also serves as Openboxbuntu
[01:08] <Unit193> phillw: You're in it!
[12:05] <escapereality> Hey #lubuntu, why can't I get my lightdm greeter top panel transparent (lubuntu 13.04)? Sry for noob question...
[14:02] <bxyrk> i'm just gonna throw something out there... after installing vino some instructions online told me to log out and back in... and afterwards i can't log in using that particular user with any desktop choice... what can i check or hose to get around it, any help would be super appreciated!
[14:07] <bxyrk> ok, sorry folks... i fixed it. i had uninstalled vino when i couldn't log in, but i logged into the box with an x forwarded ssh session and reinstalled vino and opened the preferences and disabled it... doh!
[15:57] <pip__> is the 13.10 ubiquity installer still broken?  I mean does it still freeze at any point?
[15:59] <SonikkuAmerica> Haven't checked.
[21:59] <LuvLinuxOS> hi all
[22:05] <taoseeker> hi
[23:51] <melodie> hi
[23:53] <Unit193> Howdy.


[06:38] <Logan> Unit193: I think you need an FFe for Bug 1561820
[06:50] <Unit193> Logan: Wouldn't think so, it's entirely new so can't really break anything.  At least that was my understanding of stuff.
[06:50] <Logan> Unit193: https://wiki.ubuntu.com/FeatureFreeze
[06:50] <Unit193> Though, will have to look tomorrow as to where I saw that..
[06:50] <Logan> "At this point we stop introducing new features, packages, and APIs, and concentrate on fixing bugs in the development release."
[06:52] <Logan> yeah, it's iffy territory
[06:52] <Unit193> Oh well, that was a nice one.  WONTFIX it I guess then, or I can tomorrow as I file another bug for something else. :P
[06:53] <Logan> I asked in ~ubuntu-release
[06:53] <Logan> er
[06:53] <Logan> #ubuntu-release
[06:54] <Logan> from what I recall, they usually prefer a backport later on at this point
[06:54] <Unit193> PPA is easier. :P
[06:56] <Unit193> Anywho, thanks for checking.


[13:50] <tseliot> mamarley, ricotz: the changelog.Debian.gz for both amd64 and i386 share the same md5sum in bionic in the PPA. I wonder if the issue is just in disco
[13:52] <tseliot> hmm... same goes for 19.04


[03:41] <mup> Bug #1812605 opened: snap find crached <Snappy:New> <https://launchpad.net/bugs/1812605>
[06:07] <mborzecki> morning
[07:13] <zyga> Hi
[07:14] <zyga> A bit in recovery mode
[07:14] <mborzecki> zyga: hey
[07:14] <zyga> Fell off the stairs last night
[07:14] <mborzecki> zyga: oi, are you ok?
[07:14] <zyga> I may join standup but don’t wait for me
[07:15] <zyga> When I can I will work on packaging
[07:15] <zyga> So so
[07:15] <mborzecki> zyga: was the trip back ok at least? :)
[07:15] <zyga> Some bruises and stuff like that. Some more back pain
[07:16] <zyga> Currently with wife for pregnancy checkup
[07:16] <zyga> Yeah, the trip was ok :-)
[07:16] <zyga> Just long and not much sleep on the way
[08:09] <mup> PR snapd#6294 closed: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6294>
[08:12] <mborzecki> yay
[08:12] <mborzecki> mvo: hey
[08:15] <mup> PR snapd#6391 closed: tests: simplify interfaces-contacts-service test <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6391>
[08:16] <mvo> hey mborzecki - good morning!
[08:16] <mvo> mborzecki: yeah, indeed yay :)
[08:16] <mborzecki> mvo: 1.9 is the new minimum now?
[08:16] <mvo> mborzecki: correct, we should probably update our readme too
[08:17] <mborzecki> mvo: hm there's no metion of any particular go version in the readme
[08:18] <mvo> mborzecki: yeah, I think we soon add a mention
[08:18] <mvo> mborzecki: its not OMGnow important though :)
[08:18] <mvo> mborzecki: also I just sent a mail out to foundations, security, sru etc to make sure they know we really did that, we did discuss it but I want to double check noone is unaware
[08:19] <mvo> geh, everyone is aware (double negatives are terrible!)
[08:19] <mborzecki> we can replace golang.org/x/net/context with context now
[08:19] <mborzecki> and update govendor too
[08:21] <mvo> mborzecki: yes, lets discuss in the standup. I would like to wait until we got feedback from foundations/security etc to make sure we don't need to revert anything. but having PRs will be good
[08:22] <mborzecki> i can do a quick cleanup and open a PR if we are greenlit to move forward with this
[08:29] <mvo> mborzecki: sounds great, please do
[08:30] <mborzecki> wow, we even used ctxhttp
[08:37] <mborzecki> 35 files changed, 36 insertions(+), 66 deletions(-)
[08:37] <mborzecki> not an awful lot
[08:38] <mvo> nice
[08:40] <mborzecki> golang.org/x/net/context/ctxhttp goes away, but x/net/context is imported by tomb, so it has to stay around
[08:41] <mvo> mborzecki: ok
[08:58] <mborzecki> we could also drop the check for numerical http return codes
[08:58] <mborzecki> and use consts from net/http
[09:02] <mup> PR snapd#6402 opened: spread: increase default kill-timeout to 30min <Created by mvo5> <https://github.com/snapcore/snapd/pull/6402>
[09:09] <Chipaca> morning peeps
[09:12] <mvo> Chipaca: hey, good morning!
[09:12] <mborzecki> Chipaca: morning
[09:17] <mup> PR snapd#6403 opened: many: cleanup golang.org/x/net/context <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
[09:34] <mvo> mborzecki: nice, thank you!
[09:34] <mvo> mborzecki: looks like unit tests are unhappy in this PR, seems like new stuff that the new go checks
[09:34] <mborzecki> mvo: mhm, pushing in a minute
[09:34] <mvo> mborzecki: also only in tests so shouldn't be bad :)
[09:34] <mvo> mborzecki: no worries, just wanted to let you know
[09:34]  * mvo is quite happy about this PR
[09:45] <mborzecki> mvo: and pushed
[09:49] <mvo> ta
[10:11]  * Chipaca removes 1.6, installs 1.10
[10:11]  * Chipaca feels like it's a party
[10:12]  * mborzecki can drop 1.6 gofmt wrapper now
[10:15] <Chipaca> oooh, there's a bunch of things we can drop
[10:15] <mborzecki> Chipaca: can you take a look at #6403 ?
[10:15] <mup> PR #6403: many: cleanup golang.org/x/net/context <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6403>
[10:16] <Chipaca> mborzecki: egrep -r --exclude-dir vendor '// \+build \!?go'
[10:17] <mborzecki> mhm
[10:17] <Chipaca> I need to double-check but IIRC ctrl17 was good up to 1.10 at least
[10:17] <mborzecki> Chipaca: was there some fancy json decoding too?
[10:17] <Chipaca> 1.11 might be using an even newer unicode but ctrl didn't see much change
[10:18] <Chipaca> mborzecki: ctrl is part of that, if you mean the 'clean' json
[10:18] <Chipaca> but
[10:18] <Chipaca> mborzecki: there are places where we use *json.RawMessage instead of json.RawMessage, that we could drop
[10:18] <Chipaca> and see some perf improvement
[10:18] <Chipaca> perhaps
[10:18] <mborzecki> pr by pr :P
[10:20] <Chipaca> ep
[10:30] <Chipaca> had to get https://packages.ubuntu.com/bionic/amd64/golang-golang-x-tools by hand to get godoc to play nice again
[10:30] <Chipaca> (i'm on xenial here)
[10:31]  * sparkiegeek wonders if Chipaca could have used https://launchpad.net/adapt
[10:33] <Chipaca> sparkiegeek: no idea what that is :-)
[10:34] <Chipaca> ah
[10:34] <Chipaca> sparkiegeek: no need to rebuild the package, it just works as is
[10:35] <sparkiegeek> Chipaca: it installs Ubuntu packages from 'other' series in a LXD and wraps them to make a cheap way of getting package X available from a given series
[10:35]  * Chipaca imagines using X from bionic o n xenial, and shudders
[10:36] <sparkiegeek> hah :)
[11:19] <zyga> o/
[11:19] <mvo> hey zyga
[11:19] <zyga> hey mvo :)
[11:19] <mvo> zyga: welcome back!
[11:20] <mvo> zyga: but please take it easy today
[11:20] <zyga> mvo: I'm sorry about expensify, it's super easy to click the wrong button while on the go
[11:20] <zyga> (about that "let me expense one coffee thing")
[11:20] <zyga> I'm sorting out my travel topics now
[11:20] <zyga> and recovering after the small accident yesterday :)
[11:20] <zyga> but all will be fine
[11:21] <zyga> anything urgent, any news?
[11:22] <mvo> zyga: no fires
[11:22] <mvo> zyga: your go-1.10 pr is in \o/
[11:23] <zyga> I noticed, thank you, good idea to notify other teams about that
[11:49] <mborzecki> zyga: looking into bcond_with{,out}, do we have 15.0 image for spread?
[11:51] <zyga> mborzecki: mmm, not sure
[11:51] <zyga> if you have a branch I have all the VMs ready
[11:51] <zyga> oh
[11:51] <zyga> one thing
[11:51] <zyga> so
[11:51] <zyga> tl;dr; I spent last week working on top of ubuntu in hyper-v and multipass also on top of hyperv
[11:52] <zyga> mborzecki: I think we could start standardizing on using multipass for test-builds on native kernel
[11:52] <zyga> it's very flexible and qucick
[11:52] <zyga> quick*
[11:52] <mborzecki> does it work well with non ubuntu vms?
[11:52] <zyga> yes
[11:52] <zyga> only requirement is cloud-init in the image
[11:52] <zyga> I've got a pipeline for debian builds now
[11:53] <zyga> http://download.opensuse.org/repositories/Cloud:/Images:/Leap_42.3/images/
[11:53] <zyga> I will give this a try (though not with any priority today)
[11:54] <zyga> mborzecki: it's as simple as "multipass launch $URL-to-qcow2 -c 10 -m 4G -n vm-name
[11:54] <zyga> then you have multipass commands to exec stuff inside, copy stuff around, shell interactively
[11:54] <zyga> multipass handles networking and caching
[11:54] <mborzecki> ah, haven't tried anything else than ubuntu with multipass yet
[11:55] <mborzecki> what if the image has no cloud-init?
[11:55] <zyga> nogo
[11:55] <zyga> I think it's a requirement
[11:55] <zyga> ask Saviq once he's back
[11:55] <Saviq> I'm here
[11:55] <mborzecki> Saviq: is cloud-init a hard requirement?
[11:56] <Saviq> yes, otherwise we can't access the launched instance
[11:56] <zyga> Saviq: did I say thank you for multipass, it's awesome
[11:56] <Saviq> mborzecki: otherwise you'd need to know (and pass it to us) a default username/password
[11:57] <Saviq> and we don't support that right now, nor look forward to it really
[11:57] <zyga> mborzecki: does arch have any cloud images?
[11:57] <zyga> everything else we support has them
[11:58] <Saviq> anything else, we'd need to expose a graphical and/or serial console
[11:58] <mup> PR snapd#6404 opened: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
[11:58] <Saviq> and it'd be a hands-free experience from then as far as multipass is concerned
[11:58] <mborzecki> zyga: nah :P no cloud images afaik
[11:58] <mborzecki> you can probably build one
[11:58] <mborzecki> well, we built one for spread
[11:58] <mborzecki> but it's not using cloud-init afaik
[11:59] <Saviq> probably has a well-know root password :)
[11:59] <Saviq> +n
[11:59] <mborzecki> yup, something no trivial, like 123 :P
[11:59] <Saviq> https://wiki.archlinux.org/index.php/Cloud-init
[12:00] <Saviq> https://wiki.archlinux.org/index.php/Arch_Linux_AMIs_for_Amazon_Web_Services
[12:00] <Saviq> may very well be possible to use those
[12:01] <mborzecki> mh
[12:02] <mborzecki> Saviq: while at it, is it possible to launch throw-away instances with multipass? i often work directly with cloud images and use qemu .. -snapshot
[12:04] <Saviq> mborzecki: we have a handful of approaches planned for speeding up boot, but we're unlikely to add full snapshot support any time soon, don't want to become just another CLI for hypervisors
[12:13] <mup> PR snapd#6405 opened: run-checks: ensure we use go-1.10 if available <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6405>
[13:35] <zyga> mvo: mount error still happens
[13:35] <zyga> error: cannot perform the following tasks:
[13:35] <zyga> - Mount snap "network-consumer" (unset) ([start snap-network\x2dconsumer-x1.mount] failed with exit status 1: Job for snap-network\x2dconsumer-x1.mount failed.
[13:35] <zyga> See "systemctl status "snap-network\\x2dconsumer-x1.mount"" and "journalctl -xe" for details.
[13:35] <zyga> )
[13:35] <zyga> this is from the PR above
[13:46] <Chipaca> zyga: is the go version relevant enough to be in 'snap version'?
[13:46] <zyga> Chipaca: dunno
[13:46] <zyga> perhaps?
[13:46] <Chipaca> zyga: or would this be a case for a --verbose flag or sth?
[13:46] <zyga> yeah
[13:46] <zyga> or even a debug
[13:46] <zyga> snap debug build-info
[13:46] <Chipaca> i mean, if it's for the tests, just add a 'go version' :-)
[13:46] <zyga> could show other helpful stuff
[13:46] <zyga> +1
[13:46] <zyga> go version can be elusive :)
[13:46] <zyga> if we have many
[13:51] <Chipaca> ooh, ooh! I remembered what I wanted to do when we moved past 1.7!
[13:52] <Chipaca> https://gist.github.com/chipaca/10ecdf364db962c9b5ee590f0f610b2a
[14:08] <zyga> sorry for cutting me video feed but I'm out of power on the phone
[14:13] <Chipaca> zyga: we lost you
[14:22] <mvo> zyga: yeah, cachio mentioned this as well, on what system did that happen for you?
[14:32] <zyga> mvo: that was in the PR you sent, I don't recall
[14:32] <zyga> mvo: I only saw it there
[14:38] <zyga> small helper I use for packaging work
[14:38] <zyga> packaigng helper https://www.irccloud.com/pastebin/oPwDE5pt/
[14:38] <zyga> mvo: ^
[14:39] <zyga> mborzecki: ^
[14:41] <mborzecki> hm we should add a multipass backend to spread :)
[14:43] <mup> PR # closed: snapd#5644, snapd#5822, snapd#5962, snapd#6016, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6280, snapd#6281, snapd#6313, snapd#6320, snapd#6322, snapd#6324, snapd#6325,
[14:43] <mup> snapd#6327, snapd#6329, snapd#6333, snapd#6341, snapd#6347, snapd#6348, snapd#6356, snapd#6360, snapd#6363, snapd#6367, snapd#6376, snapd#6380, snapd#6381, snapd#6383, snapd#6387, snapd#6389, snapd#6394, snapd#6396, snapd#6400, snapd#6401, snapd#6402, snapd#6403, snapd#6404, snapd#6405
[14:43] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
[15:07] <cachio> mvo, should I remove the manual from debian sid after the imagge is updated?
[15:07] <mvo> cachio: yeah, lets try that
[15:07] <mvo> cachio: once its updated, lets push a PR that enables sid again
[15:07] <cachio> mvo, sure, thanks
[15:07] <mvo> cachio: and then we can check how well that goes - it will be a good prep for the packaging merge PR. thank you!
[15:54]  * cachio lunch
[16:28] <om26er> popey, ping
[16:28] <popey> om26er: hi
[16:28] <om26er> popey, could you take a look at this one https://github.com/asciinema/asciinema-snap/issues/1#issuecomment-454529232
[16:28] <popey> will do
[16:42] <mup> PR snapd#6406 opened: tests: enable debian sid as part of the main suite on travis <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6406>
[16:43] <zyga> my debian foo has grown the SBUILD_SHELL trick
[16:53] <mvo> I uploaded new test-snapd-dbus-{consumer,producer} snaps to edge, if tests suddenly explode, this is why
[16:56] <mvo> (the PR below addresses this)
[16:56] <mup> PR snapd#6407 opened: tests: get test-snapd-dbus-{provider,consumer} from the beta channel <Created by mvo5> <https://github.com/snapcore/snapd/pull/6407>
[17:01] <mup> PR snapd#6408 opened: tests: add spread test for system dbus interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/6408>
[17:41] <zyga> wooot
[17:41] <zyga> I solved the debian unit test failures :)
[18:56] <cachio> zyga, this is the error you have fixed? https://paste.ubuntu.com/p/cmQTKpDhh6/
[18:56] <zyga> no
[18:57] <zyga> this is a known issue about go fmt changing behavior across go versions
[19:00] <cachio> zyga, ahh, ok
[21:01] <mup> Bug #1812751 opened: Several remove event for unknown device <Snappy:New> <https://launchpad.net/bugs/1812751>


[00:33] <bobbob1016> I managed to get 5.1 working over spdif from VLC, from desktop, not from myth, and not from mplayer, I'm using pulse.  My myth settings are set to "ALSA:pulse" for audio, any ideas?
[00:58] <mandingoceo> hello all i have a quick question
[00:58] <mandingoceo> !help
[00:59] <superm1> !ask | mandingoceo
[01:00] <superm1> huh? no zinn..
[01:00] <superm1> rhpot1991, ^
[01:01] <mandingoceo> ok i have an hvr1600 in my computer with kubuntu on it but the backend wont find the card but when i had mythbuntu on it it worked with no problems
[01:01] <superm1> what version of each?
[01:01] <mandingoceo> 810
[01:02] <superm1> did you make sure updates were done all the way for both?
[01:02] <mandingoceo> yes all updates are done
[01:04] <superm1> then perhaps permissions related problems?
[01:04] <superm1> are the devices populated in /dev?
[01:05] <mandingoceo> im a noob so please bear with me
[01:06] <mandingoceo> if you mean under where capture setup no
[01:07] <superm1> well if you are a noob, would it be too much to ask to just install mythbuntu again, and then add the kubuntu options?
[01:08] <superm1> it might alleviate what would be a lot of debuggin
[01:08] <superm1> kubuntu can be added to mythbuntu in the mythbuntu control centre
[01:08] <mandingoceo> didnt want to go that route
[01:09] <mandingoceo> i am computer literate just new to linux
[01:11] <superm1> well you should rule out the obvious things then first.  1) make sure your device is listed in the output of the lspci tool
[01:11] <superm1> 2) look for error messages in the dmesg tool
[01:11] <mandingoceo> did everything was fine there
[01:11] <superm1> 3) check to make sure you are in the mythtv group (look at the output of groups)
[01:11] <tritium> superm1: it doesn't look like you're subsribed to bug 153185, but I think that might be nice to try to get into jaunty
[01:12] <mandingoceo> i added my self to the group also
[01:13] <superm1> mandingoceo, well i dont have much more time for helping debug right now, i'd recommend making a post on the forums
[01:13] <mandingoceo> k thanks
[01:13] <superm1> tritium, can you get a debdiff on the bug and subscribe ubuntu-universe-sponsors then?
[01:14] <tritium> superm1: ok.  Also, not sure if you ever saw my note to you sometime back that to do hdhomerun-config properly, I'd need to split out the library into a separate package.
[01:15] <tritium> I submitted a few other bug reports or comments, that don't seem to be getting anyone's attention.
[01:16] <tritium> Bug 321076
[01:18] <hads> People aren't paid to work on things
[01:18] <tritium> I also submitted a patch for /usr/share/hal/fdi/preprobe/20thirdparty/lirc.fdi to fix the DViCO Fusion Remote MCE, but it's not showing up in my subscribed bugs.  Strange...
[01:19] <tritium> hads: I know...
[01:21] <quaa_> anyone know what "I added a shlibs file with information about libvdpau in the nvidia package.." means?
[01:22] <quaa_> im trying to update my system and nvidia-180-libvdpau wont update
[01:22] <quaa_> so i spend some hours looking online and found this site - http://forums.whirlpool.net.au/forum-replies-archive.cfm/1127495.html
[01:26] <sloof3> I missed my opportunity to format my 3TB array. I've stopped the installation before MythTV setup.  I installed gparted but it's having some unknown problem formatting the xfs partition.  What course of action do I have?
[01:28] <sloof3> http://pastebin.com/m1f804605
[01:57] <sloof3> After a little searching maybe I have to use the 64-bit version
[01:57] <sloof3> Looks like my partition limit is 2.2TB
[02:30] <MythbuntuGuest34> is there a actual .iso image for mythbuntu
[02:30] <tgm4883_laptop> yea
[02:30] <tgm4883_laptop> at mythbuntu.org
[02:31] <MythbuntuGuest34> click and download?
[02:31] <tgm4883_laptop> yea
[02:31] <MythbuntuGuest34> where
[02:32] <MythbuntuGuest34> i downloaded somthing but i got 7 or 8 files
[02:32] <MythbuntuGuest34> none with a .iso extension
[02:34] <uSlacker> Hey Mythbuntu gurus - I need your help.  When I load the proprietary ATI drivers for my Diamond HD 2600XT, the mythbuntu frontend gets corrupt
[02:34] <uSlacker> if I exit out of the front-end, *buntu underneath looks fine
[02:41] <tgm4883_laptop> MythbuntuGuest34, http://www.mythbuntu.org/downloads
[02:42] <sloof3> MythbuntuGuest34: Don't right-click and Save the first Link
[02:44] <MythbuntuGuest34> i aLSO BURNED THE FIRST CD AND IT SORTA WORKED IT DIDN'T ALLOW ME TO BOOT from the cd in the boot menu
[02:45] <MythbuntuGuest34> sorry hit caps lock
[02:49] <MythbuntuGuest34> how do i save the first link without right clicking
[02:54] <tgm4883_laptop> MythbuntuGuest34, left click on it?
[02:55] <MythbuntuGuest34> it gives me a wierd site
[02:56] <tgm4883_laptop> what weird site?
[02:56] <hads> wget http://osuosl.cdimages.mythbuntu.org/mythbuntu-8.10-desktop-proper-i386.iso
[02:56] <sloof3> ...wtf
[02:56] <sloof3> MythbuntuGuest34: Don't right-click, click the first Link
[02:57] <MythbuntuGuest34> nvm i know what i did wrong i extreacted the files with win zip instead of leaving it as a iso
[02:57]  * sloof3 pulls trigger on revolver
[02:58] <MythbuntuGuest34> ?
[02:59] <MythbuntuGuest34> i also don't know to to get rid of the slection between vista and mythbuntu when i first boot my computer
[04:02] <superm1> tritium, that's fine if you need to split it.  same thing, submit a diff and subscribe u-u-s
[04:02] <superm1> and ping me if you aren't getting a response out of the queue
[04:03] <mandingoceo> i have a permission problem with my card and myth and cant figure it out
[04:04] <mandingoceo> i dont have permission to /dev/video0
[04:04] <mandingoceo> kubuntu 810
[04:04] <superm1> mandingoceo, i'm back now.  so if that's the case, then you need to add your user to generally the video group i think
[04:05] <superm1> check who owns /dev/video0
[04:05] <mandingoceo> k
[04:09] <mandingoceo> i added my self and myth to the video group
[04:11] <mandingoceo> from the terminal when i enter mythbackend i get the error no valid capture cards
[04:12] <mandingoceo> i read on a website some where where u posted cat /dev/video0 > ~/test.mpg to test the cards
[04:12] <mandingoceo> i do that i the mpg plays
[04:13] <superm1> that's only on hardware that supports analog v4l
[04:13] <superm1> digital hardware will show up in /dev/dvb
[04:13] <mandingoceo> i have the hvr 1600
[04:14] <mandingoceo> so i was connected to the analog input
[04:14] <superm1> well does the analog side work in linux though
[04:14] <superm1> have you checked on that already?
[04:14] <mandingoceo> no still get the permission denied
[04:14] <mandingoceo> and now the backend doesnt see the card
[04:16] <superm1> the permission denied may just be a red herring is what i am getting at
[04:16] <superm1> if the analog portion of the card doesn't work in linux
[04:16] <mandingoceo> oh
[04:17] <superm1> well it looks like it should all work according to http://www.mythtv.org/wiki/Hauppauge_HVR-1600
[04:20] <mandingoceo> yeh i looked at that
[04:24] <mandingoceo> superm1 what does this mean MainServer::HandleVersion - Client speaks protocol version 31 but we speak 40!
[04:25] <superm1> that u are using the wrong version of a package
[04:25] <mandingoceo> ok
[04:26] <superm1> so maybe your backend is running 8.10 and your frontend 8.04
[04:26] <superm1> or something like that
[04:26] <mandingoceo> oh ok
[04:26] <superm1> somehow you've mixed older packages in
[04:27] <mandingoceo> so how can i redown load all the right ones
[04:28] <superm1> well i dont know where you got the wrong ones from
[04:28] <superm1> so i'd recommend undoing whatever you did to get the wrong ones on there
[05:16] <Suidog> hey there.  I'm having a problem with my backend. I'm running ubuntu 8.04 and everything seems to be working now after a bit of tweaking but it doesn't seem to be able to use my tuner card
[05:17] <Suidog> I see that it's loaded in dmesg as cx88 /dev/video0 and /dev/video1
[05:19] <Suidog> but when I look at the log for backend I see the following: channelbase(1) Error: InitializeInputs()
[05:19] <Suidog> anyone know what I could look at next?
[05:19] <Suidog> anyone alive in here?
[05:33] <mandingoceo> superm1 u still there
[05:37] <mandingoceo> ok got it working just keeps pausing though
[05:42] <mandingoceo> any1 home
[05:45] <Suidog> ok.. got some new stuff. I created the input group .. but now I just get a black screen when I go to watch live tv
[05:46] <Suidog> Mandingoceo .. is anyone responding in here?
[05:47] <mandingoceo> superm1 was but not anymore
[05:48] <Suidog> man .. all these people and no is here!
[05:49] <Suidog> it's like they have a life or something!! What gives! LOL
[05:49] <foxbuntu> mandingoceo, are you using an HVR-1600 with QAM or just ATSC/NTSC?
[05:49] <mandingoceo> yeh right
[05:50] <mandingoceo> qam
[05:50] <foxbuntu> Mythbuntu 8.10?
[05:50] <mandingoceo> kubunto 810
[05:50] <foxbuntu> hmm ok
[05:50] <Suidog> man I'm so close now..  I'm missing something
[05:51] <foxbuntu> sorry, I am having issues of my own
[05:51] <mandingoceo> scan your channels
[05:51] <foxbuntu> mandingoceo, my 1600 says no signal
[05:51] <mandingoceo> how do u have the card setup
[05:51] <Suidog> on the input I told it to use the channels from the listings
[05:51] <mandingoceo> k
[05:51] <foxbuntu> mandingoceo, the QAM goes to the middle RG6 jack right?
[05:51] <mandingoceo> yes
[05:52] <foxbuntu> ok
[05:52] <Suidog> man: asking me how I have it setup?
[05:52] <mandingoceo> yeh
[05:52]  * foxbuntu goes to build a new 8.10 machine to test with
[05:52] <Suidog> well I'm running 8.04 and my card had drivers loaded for it .. saw it in dmesg
[05:53] <Suidog> went in and selected the video0 as capture card
[05:53] <mandingoceo> k
[05:53] <Suidog> pull listing from for comcast in my area
[05:53] <Suidog> created input group with that source
[05:53] <Suidog> should I be doing anything else?
[05:53] <mandingoceo> what does your logs say
[05:54] <mandingoceo> cat /var/log/mythtv/mythbackend.log
[05:54] <Suidog> ah.. seeing a unknown codec error now
[05:55] <Suidog> it says go into profiles..
[05:55] <Suidog> profiles on backend?
[05:56] <Suidog> I didn't see a place to select codecs
[12:53] <jaymzh> Hey all. I changed my sources.list to intrepid, did an 'apt-get dist-upgrade', rebooted and the mythtv frontend is completely unresponsive. Nothing in the frontend logs except that it couldn't run cdrecord and couldn't register SIP. The frontend is completely unresponsive to keyboard input.
[12:54] <jaymzh> an strace shows it trying to do selects over and over but getting EGAIN
[13:00] <jaymzh> If I run mythtv-setup from another machine over x-forwarding, it works fine, I can select stuff... but from console, it doesn't work
[21:13] <MythbuntuGuest23> hello, i can dump raw video from my pvr-150 but i cannot open a channel through mythtv. the screen goes black and it never shows video. i made sure to set permissions on my recordings folder. where should i start troubleshooting?
[21:14] <MythbuntuGuest23> im using seperate back and frontend
[21:15] <tgm4883_laptop> MythbuntuGuest23, you should start by pastebinning your logs
[21:15] <tgm4883_laptop> !pastebin
[21:15] <Zinn> when pasting more than 5 lines of data please use http://mythbuntu.pastebin.com so you don't flood the channel.  Then please post the link in the channel.
[21:15] <tgm4883_laptop> !logs
[21:15] <Zinn> MythTV logs are stored in /var/log/mythtv/   You can use mythbuntu-log-grabber from the Applications menu to automatically post the most relevant logs to our pastebin.
[21:16] <tritium> MythbuntuGuest23: lucky that you have a PVR-150.  They don't sell them anymore, and analog on the newer cards (I have the WinTV-HVR-1800) is pathetic.
[21:16] <tritium> It's basically only good as an ATSC card.
[21:18] <tgm4883_laptop> analog is overrated
[21:18] <MythbuntuGuest23> yeah
[21:18] <MythbuntuGuest23> it looks really good
[21:18] <MythbuntuGuest23> i have always loved hauppauge
[21:18] <tgm4883_laptop> And I finally get to start complaining about the President for making dumb decisions
[21:18] <MythbuntuGuest23> what log should i pastebin?
[21:19] <tritium> Analog is what comes out of my DirecTV receiver.  Without it, I'm down 80% of my channels.
[21:19] <tgm4883_laptop> moving back the digital turn off date
[21:19] <tgm4883_laptop> bah
[21:19] <tgm4883_laptop> tritium, as does mine
[21:19] <tgm4883_laptop> you need to get an HDPVR
[21:19] <tgm4883_laptop> as do I ;)
[21:19] <MythbuntuGuest23> isnt it like /var/logs/mythtv or something?
[21:19] <tritium> I don't have DirecTV high-def.
[21:20] <tgm4883_laptop> MythbuntuGuest23, use mythbuntu-log-grabber
[21:20] <tgm4883_laptop> it will give us the logs we need
[21:20] <tritium> The HD-PVR wouldn't do much for me.  Besides, I don't want another external box.  I already have an HDHR.
[21:20] <tgm4883_laptop> note that I posted the two things you needed above
[21:22] <MythbuntuGuest23> http://mythbuntu.pastebin.com/f49dda70e
[21:23] <MythbuntuGuest23> i just clicked on watch tv right before i ran that log
[21:24] <MythbuntuGuest23> if there is something else i need to do let me know
[21:29] <MythbuntuGuest23> speaking of that pvr-150 i have an all in wonder and another card somewhere and the difference in encoding quality is unreal
[21:29] <MythbuntuGuest23> for some reason that pvr-150 looks 10 times better pulling cable straight from analog
[21:36] <MythbuntuGuest23> yeah i can do cat /dev/video0 > whatever.mpg and pull video from my card. so i know its working. but when i connect my frontend to the system it wont open any channels
[21:37] <MythbuntuGuest23> and the frontend is really slow for some reason. i dont know if it is locking up or if it is just having a hard time.
[21:37] <MythbuntuGuest23> i just realized my transfer speed from backend to frontend is only 100kbps
[21:39] <tgm4883_laptop> MythbuntuGuest23, strange, that log isn't showing me anything
[21:39] <tgm4883_laptop> hmm
[21:40] <tgm4883_laptop> is that from your backend or your frontend?
[21:40] <tgm4883_laptop> or is it the same maching?
[21:41] <MythbuntuGuest23> that is from my backend
[21:41] <MythbuntuGuest23> should i restart the backend, try to watch somethine and then pastebin the log again?
[21:53] <MythbuntuGuest23> holy shit
[21:53] <Zinn> MythbuntuGuest23: Please watch your language.
[21:53] <MythbuntuGuest23> it start working
[21:54] <MythbuntuGuest23> now i need to lookup the controls for this
[21:54] <MythbuntuGuest23> :)
[21:57] <MythbuntuGuest23> now to get rid of mythfrontend and replace it with xbmc
[21:57] <MythbuntuGuest23> is that a good or bad idea?
[21:58] <quaa> hey i have a problem, just installed my system using weekly builds and now when trying to run mythtv-setup it crashes before i get a menu displaying anything
[21:59] <quaa> logs look good i believe
[22:00] <quaa> im using http://www.mythbuntu.org/auto-builds using trunk
[22:00] <kayle12> quaa: what theme are you using?
[22:01] <quaa> just installed the system so i havent picked a theme yet
[22:02] <kayle12> ahhh: ok well i had a problem the other day and it was the theme that caused it
[22:03] <quaa>  hmm i mean generally i dont have any problems but im confused with this
[22:05] <quaa> ohhh hmm
[22:05] <quaa> i loaded up mythfrontend and picked G.I.A.N.T
[22:05] <quaa> and its working now i guess
[22:06] <kayle12>  good must have been a slight error..
[22:06] <quaa> goot call man!
[22:10] <MythbuntuGuest23> how much transfer speed do i need between my back and frontend?
[22:10] <MythbuntuGuest23> because my backend is connected with a crappy wireless card
[22:11] <MythbuntuGuest23> im getting like between 50 and 100kbps transfer. and  its skipping really bad
[22:12] <MythbuntuGuest23> my backend and frontend are also seperated by 2500 feet
[22:45] <quaa> hmm
[22:51] <quaa> got different problems now.  Ran the backend setup and setup my pvr-150, now the things that dont work are themes (only ones that i tried that works is G.A.N.T. and blue
[22:51] <quaa> and when trying to "Watch TV" the frontend crashes
[22:54] <quaa> What i did was install mythbuntu 8.10 AMD64 from alternate cd (must use for my softraid) and updated everything, then did dist-upgrade, then installed the nvidia-180-glx / modaliases from https://launchpad.net/~anders-kaseorg/+archive/ppa
[22:54] <quaa> Then i added the trunk repo from http://www.mythbuntu.org/auto-builds and updated again
[22:54] <quaa> then dist-upgrade again, everything is up to date now.
[22:55] <quaa> logs are @ http://mythbuntu.pastebin.com/f1bcfcc27
[22:56] <stiev3> MythbuntuGuest23, too many variables are involved with wireless to really call that one I think.  You should definitely push for a wired connection.  Ballpark maybe ~13Mbps assuming 6g/hour or ~3Mbps for standard def 1g/hour.
[22:56] <sloof3> Should I be having trouble tuning QAM channels with the HVR 1250 in 8.10?
[23:00] <stiev3> MythbuntuGuest23, I think you're nearing 1Mbps at the top end, (if my bits/bytes conversion isn't retarded)
[23:01] <stiev3> MythbuntuGuest23, and that's assuming your card is in fact maintaining that rate, which with wireless cards tends to vary hugely and at a distance of half a mile from the access point... these parameters sound too extreme for reliable wireless mythtv
[23:11] <quaa> video from the capture card works in VLC but not in mythfrontend
[23:19] <rhpot1991> quaa: I think those trunk packages are busted
[23:21] <quaa> i believe its something with the nvidia-180 driver, i have asked multiple people and they say that i can use this driver (with vdapu) even though my 7600GT does not support vdapu - they said that it will not use the vdapu
[23:22] <quaa> here is my mythfrontend verbose output http://mythbuntu.pastebin.com/m4552185c
[23:24] <rhpot1991> I'd guess either those packages are broken or you don't have the correct driver for VDPAU or your card doesn't support it
[23:24] <rhpot1991> last I heard there was something wrong with the trunk packages, might want to find out if they are ok
[23:25] <quaa> well to get rid of the trunk packages (if they are busted) could i just remove the source from my list
[23:25] <quaa> and update
[23:25] <quaa> or would i have to reinstall
[23:26] <rhpot1991> you will have to remove the packages that were installed as well
[23:26] <rhpot1991> otherwise there is nothing "newer" to upgrade to
[23:27] <rhpot1991> you can force specific versions as well, but its cleaner to get rid of the old then reinstall the packages
[23:27] <quaa> does the .21 fixes repo on http://www.mythbuntu.org/auto-builds still work?
[23:27] <rhpot1991> yes
[23:27] <quaa> see the original reason i am trying to use the trunk is because when i was using my HDTV tuner on live tv
[23:28] <quaa> and click guide everything became unresponsive
[23:28] <quaa> and i read somewhere that the fixes/trunk repo is suppose to fix this problem
[23:28] <quaa> it was something to do with deinterlacing in the guide
[23:29] <rhpot1991> !%guide%
[23:29] <Zinn> If you have a slow guide in Live TV, this is most likely due to the bob deinterlacer.  Please try disabling this deinterlacer and test again.  If this is the case please report back.
[23:29] <rhpot1991> try that?
[23:29] <rhpot1991> also trunk has a ton of HD improvements, but its not really ready for most users
[23:29] <rhpot1991> still in development and all, so its not recommended unless you really know what you are doing
[23:30] <quaa> yeah that is why i am wanting to use the trunk
[23:30] <quaa> i can figure some of this stuff out but if that repo is messed up what is the other way to get trunk running on my system
[23:31] <rhpot1991> build it from source
[23:31] <quaa> Zinn: i would try that if i could but my system is borked now!
[23:31] <rhpot1991> Zinn: is a bot he wont talk back to you :P
[23:32] <quaa> oooooo
[23:32] <quaa> my bad
[23:32] <quaa> there is no other way to use trunk other than building it from source?
[23:33] <rhpot1991> use the packages when/if they are fixed
[23:33] <rhpot1991> once again though, trunk isn't really ready for end user use
[23:34] <quaa> ok so i guess the easiest think for me then
[23:35] <quaa> is to reinstall my system, and enable the fixes repo from http://www.mythbuntu.org/auto-builds
[23:35] <quaa> ?
[23:38] <rhpot1991> quaa: shouldn't need to reinstall
[23:38] <rhpot1991> just remove all the mythtv packages
[23:39] <quaa> can i do that with mythbuntu control center?
[23:43] <rhpot1991> quaa: under "Advanced Management"
[23:44] <rhpot1991> click Launch Synaptic
[23:44] <rhpot1991> search for "mythtv" in here
[23:44] <rhpot1991> right click on the mythtv packages that are installed (green check box), and choose "mark for complete removal"
[23:45] <rhpot1991> do that for them all then apply, and they should all be gone
[23:45] <quaa> then reinstallation?
[23:45] <rhpot1991> add the fixes repo, remove the trunk one
[23:46] <rhpot1991> then you can use MCC to install whichever configuration you want
[23:46] <rhpot1991> make sure you do a "sudo apt-get update" first
[23:46] <rhpot1991> before using MCC that is
[23:46] <rhpot1991> for the reinstallation
[23:48] <quaa> k
[23:48] <quaa> trying