[01:43] <leleobhz> someone here know a document about tarball.mk on cdbs?
[01:50] <emgent> hi persia, can you open tasks in Bug #240549 ?
[01:50] <emgent> Thanks
[01:52] <persia> emgent: Yes, but it's *always* better to ask generally, rather tha poking a specific person :)
[01:54] <persia> emgent: There's no nominations to approve?  What needs doing?  Which releases are affected?  Please nominate some stuff, and ask someone to approve.
[01:54] <emgent> heheh ok persia sorry :P
[01:54] <emgent> persia: i cant nominate it.
[01:54] <emgent> ok done
[01:55] <emgent> launchpad timeout first.. now work fine
[01:56] <persia> emgent: Great.  Now check rmadison, and ask for approval in the right channel :)
[01:56]  * persia isn't core-dev
[01:56] <emgent> saw first to write debdiff
[01:57] <emgent> uok sorry, and thanks :)
[03:44] <leleobhz> running build_scripts
[03:44] <leleobhz> creating /tmp/buildd/twitteiro-1.1/build/scripts-2.5
[03:44] <leleobhz> error: Is a directory
[03:44] <leleobhz> make: *** [python-build-stamp-2.5] Error 1
[03:44] <leleobhz> someone can help me why this is happening?
[04:07] <genii> Hello. Can anyone recommend to me some good resource for: packaging from a foreign (non Debian) source,    and: working with a previous version of (ubuntu) sources in order to update it.
[04:10] <persia> genii: What are you trying to do?  Update an existing package from a new upstream source?
[04:11] <genii> persia: I think that is what it amounts to. Specifically the pdfedit is at 0.3.2 currently for Hardy, want to package 0.4.1
[04:12] <persia> genii: OK.  What's the current version in Debian?
[04:12] <genii> unstable?
[04:12]  * persia points at packages.qa.debian.org as an easy way to dig up this sort of information
[04:12] <genii> Ah, thanks
[04:12] <persia> Unstable typically, but if your preferred version is in experimental, that can also be interesting.
[04:13] <ScottK> Like the Chinese curse.
[04:13] <genii> Latest in either case in 0.4.1-1
[04:13] <genii> *is
[04:13] <persia> ScottK: Yes, well :)
[04:14] <persia> genii: Great.  Next check the current version in Ubuntu (https://launchpad.net/ubuntu/+source/pdfedit)
[04:14] <genii> Can it be then backported?
[04:14] <ScottK> !backports | genii
[04:15] <persia> genii: You've jumped ahead :)  Yes, the next step is a backport: https://help.ubuntu.com/community/UbuntuBackports
[04:16] <persia> genii: I hope you found that easier than trying to package it from scratch...
[04:18] <genii> persia: 0.4.1 has not yet seemed to have made it from 8.10 to 8.04 yet through backports.
[04:18] <persia> genii: Is there an open request yet?
[04:19] <genii> persia: A user in #kubuntu was recommended to make one, unsure if it was done.
[04:21] <genii> persia: If the scenario was only to have 0.4.1 in Hardy for myself, it would not be a large issue. The sources compile without incident. But then I embarked on a strange journey when trying to find how to package it for Launchpad.
[04:21] <persia> genii: Have you looked at launchpad.net/hardy-backports/+bugs ?
[04:22] <genii> I will look now.
[04:22] <persia> genii: Understood.  The idea is to reduce duplication of work, so everyone can share.
[04:22] <persia> The difficulty is that there is a somewhat complex process involved to make sure that work isn't duplicated.
[04:23] <persia> At the conclusion of your journey, you should expect that everyone who wants the updated version will be able to use it, as a result of your research.
[04:25] <genii> persia: Looks like they made a request (with no reply as of yet) https://bugs.launchpad.net/hardy-backports/+bug/240427
[04:26] <persia> genii: OK.  I believe the next step is for someone to build the intrepid pdfedit on hardy, and report on their success.  You'll need to use pbuilder or prevu for the build.
[04:27] <persia> ScottK: Would it be acceptable to use sbuild or cowbuilder for a test build?  If so, could the process page be updated?
[04:28] <persia> genii: Given your previous effort to update the package, are you up for the test build?
[04:28] <ScottK> persia: Yes.  The page is written primarily for non-developers, so the more accessible tools are emphasized.
[04:28] <persia> ScottK: OK.  It just says "No other build methods will be accepted" in bold print, meaning I'm not likely to backport anything :)
[04:29] <genii> persia: I might need to defer today, this is 14 hours now on the computer
[04:29] <persia> genii: OK.  To answer your original question, the easiest thing for you to do is to download the intrepid source and compile for hardy.
[04:29]  * ScottK looks at the page.
[04:30] <ScottK> persia: I'm pretty sure that was meant to exclude checkinstall and friends.
[04:30] <genii> persia: OK. With the pbuilder?
[04:30] <persia> If you follow the backports process, and update the bug when you do so, anyone else interested in the updated pdfedit will be able to use the backport (after enough testers have confirmed it).
[04:30] <persia> ScottK: I also.  I'm just being (perhaps surprisingly) pedantic.
[04:30] <ScottK> Sure.
[04:30] <persia> genii: pbuilder would work (as would tomorrow if you want a break).
[04:30] <ScottK> I'm the last one to be critical of pedantry.
[04:31] <genii> persia: I'll try tomorrow when I log in from work in about 10 hours
[04:31]  * persia considers the value of lp.net/~ubuntu-pendants
[04:31] <genii> persia: Should I come back here at that time?
[04:31] <persia> genii: Thanks.  Good luck with it.
[04:32] <persia> genii: Come back if you have questions (or just idle to see answers to other people's questions).  There's no requirement to be on IRC while you build or test pdfedit.
[04:32] <nxvl> why are we talking about pedancy?
[04:33]  * genii sips coffee and looks for his Advils
[04:33] <persia> nxvl: pedantry :)
[04:33] <nxvl> oh yes
[04:33] <nxvl> just a typo
[04:33] <nxvl> i'm SO tired
[04:33] <bimberi> nxvl: Capital 'W' :P
[04:33] <nxvl> bimberi: huh?
[04:34] <persia> nxvl: more pedantry ;)
[04:34] <bimberi> in Why.  Sorry, back to lurking and learning for me.
[04:34] <genii> persia: OK, thanks for the tips.You'll see me tomorrow :)
[04:35] <persia> genii: Probably not, as I hope to be asleep then, but someone else will be here.
[04:35] <genii> Heh :)
[04:35] <ScottK> persia: Fixed.
[04:35] <genii> Later, gentle-people
[04:35]  * ScottK goes back to ordering groceries.
[04:35] <persia> ScottK: Thanks.  Now if only I wanted to edit a PDF today...
[04:58] <Hobbsee> ScottK: proposal++
[05:26] <wgrant> ScottK: I think it's going to be a bit hard to bootstrap your new decision making process.
[05:27] <persia> wgrant: How do you mean?  (specifically, where is it likely to fail)
[05:28] <wgrant> persia: Well, we've got to make a decision on a new way to make decisions, which will be hard enough that it can't be made at a meeting.
[05:30] <persia> wgrant: Ah, right.  I was thinking that it might be a sensible pilot of the new process to use the new process to decide if the new process should be used (mind you, I'm not sure the new process as written will be the new process, but haven't yet organised my objections)
[05:40] <TheMuso> persia: I think one needs to be awake to be able to make sense of what you just said. I did, but there are that many occurrances of "new process" that it could make people's head spin. :p
[05:41] <wgrant> Pfft, only 5.
[05:41] <wgrant> And at least they do all refer to the same thing.
[05:41] <wgrant> Except one.
[05:42] <persia> Right.  Next time I'll use "foo" :)
[05:42] <TheMuso> lol
[06:42] <dholbach> good morning
[07:02] <geser> good morning
[08:09] <\sh> TheMuso: bug #239719 that's a totally new upstream version, or did I miss something from the debdiff?
[08:14] <TheMuso> \sh: I didn't check the version number, as I was more concerned at first with the changelog and what was changed before checking the version, so once I find something, I don't usually progress further with reading the diff.
[08:14] <\sh> TheMuso: I'll talk to siegfried about it...
[08:15] <TheMuso> \sh: Ok.
[08:50] <DktrKranz> ScottK: I just prepared a draftt based on what we discussed yesterday: https://wiki.ubuntu.com/StableReleaseUpdates/Draft
[08:51] <AnAnt> Hello, how can I create a diff between 2 diff files ?
[08:52] <persia> AnAnt: Interdiff is the program for that.  Note that it can be confused by certain classes of patches.
[08:53] <persia> DktrKranz: From my reading of the meeting log, it appeared that one criticism of the current policy was that it was established by MOTU SRU.  While the draft looks reasonably clear to me, please be sure to arrange that it gets appropriate validation this time so that we don't have to question it again (and can instead discuss possible specific changes).
[08:54] <AnAnt> thanks
[08:56] <persia> DktrKranz: Also, it's likely worth reviewing the specific language to make sure the filtered include at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification still works.
[08:57] <DktrKranz> oh... really
[08:59] <persia> Well, I presume so.  Best to have testers and developers looking at the same thing.
[09:04] <dholbach> how about a universe sponsoring 5-a-day? we have a lot of good stuff waiting for upload! https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-universe-sponsors
[09:04]  * dholbach processed a bunch of them today
[09:05] <persia> Why 5?
[09:05] <dholbach> do 10 if you like :)
[09:05] <Koon> 10-a-day-and-night ?
[09:05] <dholbach> Koon: :-)
[09:05]  * persia prefers to look at clearing the queue, but admits it's currently a bit of a mess.
[09:06] <DktrKranz> do-as-much-as-you-can-a-day-but-please-more-than-five
[09:07] <DktrKranz> persia: PerformingSRUVerification adjusted, thanks for noticing it
[09:08] <persia> DktrKranz: Erm.  Might not want to adjust the page until the draft is applied.
[09:08] <DktrKranz> persia: it takes directly from StableReleaseUpdates, not from /Draft.
[09:08] <persia> Ah.  That's perfect then :)  Ignore the last.
[09:08] <persia> (and it appears like it will work with /Draft cleanly as well)
[09:10] <DktrKranz> I didn't check, but I guess so, since I took tokens present in both pages
[09:10] <persia> DktrKranz: I had guessed you had checked, as it works so cleanly.  Lucky accident then :)
[09:11] <DktrKranz> yes!
[09:11] <DktrKranz> oh, this is cool: http://edos.debian.net/weather/
[09:13] <persia> DktrKranz: How hard would it be to port?  Might be interesting as a means to attract attention to some of the porting architectures.
[09:14] <DktrKranz> persia: it should be based on edos-debcheck, I think it doesn't require much work. I'll try to look if it's on Debian QA SVN already
[09:49] <Doris> lo, i've been suggested this room for my question. when running dpkg-buildpackage on a project i get "dpkg-shlibdeps: failure: no dependency information found for" - anyone know where this is fixed ? i have a depends line in my debian/control file.
[09:51] <RAOF> Doris: Sounds like you're depending on a broken library; the library package should be shipping a .shlibs file, which tells dpkg-shlibdeps what the dependencies should be.
[09:56] <DktrKranz> persia: debian weather is not online, we asked zack if he could publish it somewhere, he'll do soon. So we can look at it :)
[09:57] <persia> DktrKranz: Cool.  I'm thinking it might be also interesting for the SRU crowd: watch the weather improve.  Might also be a good metric for our release-readiness as we get to that part of the cycle.
[09:58] <DktrKranz> especially for lpia, since it is now an official port (if I'm not wrong)
[09:59] <persia> I think lpia is in the same class as everything else on ports.ubuntu.com.
[09:59] <DktrKranz> launchpad.net/ubuntu/intrepid states it's official
[09:59] <persia> Of course, we can't quite compete with Debian (I expect the sysadmins would revolt if we tried to add that many m68k buildds)
[10:01] <persia> DktrKranz: Interesting.  Last I looked there was a lot of hackery involved in lpia.  Getting that clean this cycle will be a bit of work.
[10:01] <Doris> raof, the one it depends on is one of mine too, so that's fixable. thanks. :) i take it this shlibs file normally lives in the debian dir too ?
[10:01] <directhex> what *IS* lpia?
[10:01] <wgrant> i386 with even more added specialness.
[10:01] <DktrKranz> persia: we lack real hardware to test, even if we have PPAs for test builds... but that's not enough :/
[10:01] <persia> directhex: Low Power Intel Architecture.  It's things like the A110 and Atom.  The IA is essentially IA-32, but there's a couple minor differences.
[10:01] <RAOF> Doris: The debian library packaging guide should give specifics.  dh_makeshlibs is probably what you want to look at.
[10:02] <persia> Also, the toolchain is a little different, and optimised for a different usecase.
[10:02] <wgrant> persia: Ah, so LPIA builds should be used on Atom?
[10:02] <Doris> kk thanks :)
[10:02] <directhex> persia, i was under the impression atom was a "normal" i386
[10:02] <persia> DktrKranz: At least you can buy it now.  I have an A110 laptopishthingy
[10:02] <persia> directhex: It's backwards compatible.
[10:02] <directhex> persia, why give one low-power x86 its own arch, but not another?
[10:03]  * DktrKranz should upgrade his hardware at some point... having a 9-year-old PC as primary box is not so cool
[10:03] <persia> wgrant: For best performance, for some use cases.  One might argue that one ought use amd64 on the Intel desktop series in the same way.
[10:03] <persia> directhex: How do you mean?
[10:03] <wgrant> persia: Does Atom do EMT64?
[10:03] <wgrant> I recall is lacked either vmx or emt64.
[10:03] <persia> wgrant: Nope.
[10:04] <persia> Right.
[10:04] <persia> It's also hardlocked for a maximum of 1GB RAM.
[10:04] <wgrant> Ow.
[10:04] <persia> The A110 shares those shortcomings, but still only gets me 3-hour battery life.
[10:04] <wgrant> Hopefully the post-945 Atom chipset will improve on that...
[10:05] <persia> The poulsbo stuff?  Maybe.
[10:06] <persia> .
[10:06] <directhex> persia, i'm failing to find a reference for how lpia differs from x86
[10:07] <directhex> persia, if we're talking minor compiler flag details whilst it'll still run i386 executables (+ vice versa) then what's special about lpia compared to other needs-special-love x86, like via's CMOV-free C3 chips?
[10:07]  * wgrant is hoping to replace his home router/servery thing with something Diamondville-based at some point.
[10:10] <persia> directhex: I don't have a good answer to that question.  I do know that someone in #ubuntu-mobile was talking about trying to run lpia on a Geode earlier today (but haven't heard results).
[10:11] <wgrant> Geodes are remarkably slow :(
[10:11] <directhex> wgrant, really? you REALLY think it's remarkable? i'd say it's depressingly expected, personally
[10:12] <persia> wgrant: Well, depends on your definition.  I've some slower processors around running linux if you want to have a comparison...
[10:13] <wgrant> persia: ARMs, or some old x86?
[10:13] <persia> wgrant: low-clock ARMs.  Somewhere I have an old 486DX/50 tablet, but I've not tried to load Ubuntu on it.
[10:15] <wgrant> The oldest thing I've run Linux on is our 486DX/50 laptop, and that was about 8 years ago.
[10:16] <directhex> i ran redhat on a cyrix dx2/66 once. the experience made me swear off linux for about 5 years
[10:16] <wgrant> Actually, I might have installed something on our Cyrix 40MHz desktop before that, but I forget...
[10:18] <persia> wgrant: Well, if you want to talk about history, I'll be able to trot out some ancient examples.
[10:18] <persia> Bes current is the H340, which I believe is a 50MHz ARM
[10:19] <persia> s/Bes/Slowest/
[10:19] <directhex> linux on mp3 players isn't a good thing
[10:20] <persia> directhex: Why not?  How is it different than linux anywhere else?
[10:20] <persia> Admittedly, 320x240 isn't much space, and input is limited, but...
[10:20] <directhex> persia, my player shipped with a terrible linux-based firmware. rockbox was a vast improvement
[10:21] <persia> directhex: Isn't rockbox linux?
[10:21] <directhex> and the h3xx series have a <=140mhz coldfire chip. never running at that speed though
[10:21] <directhex> persia, absolutely not. it's their own kernel
[10:21] <persia> Aha!
[10:22]  * persia is multiply enlightened, and clearly ought uninstall linux from that machine.
[10:23] <directhex> persia, http://www.rockbox.org/twiki/bin/view/Main/RockboxKernel
[10:34] <lionel> hi sylvaing :)
[10:34] <sylvaing> hi
[10:35] <sylvaing> lionel, ;-)
[10:43] <Riddell> slomo_: you need to attach the debdiff to bug 239317
[10:44] <slomo_> Riddell: done
[10:46] <Riddell> now poke motu-sru :)
[11:30] <Riddell> superm1: coreavc, a codec package without a codec?
[11:34] <Riddell> superm1: "On Debian & Ubuntu systems, a complete copy of the LGPL v2 can be found under /usr/share/common-licenses/GPL-2"  bad copy and paste?
[11:36] <Riddell> superm1: is there anything from upstream which indicates the source is GPL?
[11:38] <Riddell> superm1: are the patches for mplayer and xine used?  if not how does this package get used?
[12:12] <directhex> Riddell, is it a debconf-powered package, like quake2-data or msttcorefonts?
[12:12] <Riddell> directhex: doesn't seem to be
[12:28] <Laney> I'm getting a FTBFS when attempting to build the vegastrike package from sid. Builds fine on sid/hardy pbuilders but not in an intrepid one. Error: http://pastebin.ubuntu.com/20831/
[12:29] <directhex> pythontastic
[12:29] <Laney> Quite
[12:48] <Laney> Any insights appreciated ;)
[12:49] <directhex> don't look at me, i handle monoish things
[12:55] <ScottK> Laney: I guess I'd be looking at any Ubuntu differences in boost to see if anything looked like a likely culprit.
[12:56] <Laney> ScottK: I've looked at boost, and the same version is in Intrepid and Hardy.
[12:56] <Laney> (builds fine in Hardy)
[12:56] <ScottK> Oh.
[12:56]  * ScottK dunno then.
[12:56]  * ScottK would guess somehow the new compiler flags are screwing with you, but has no idea how.
[12:57] <geser> Laney: have you compared the version of boost-python (or how the package is called) in intrepid and sid?
[12:59] <Laney> geser: sid has -11 and intrepid has -4ubuntu3. But good idea, I'll check the BST
[12:59] <Laney> BTS
[13:02] <RAOF> Laney: I'm getting the same FTBFS with Miro, but I'm yet to really investimigate.
[13:02] <geser> Laney: you might try if using the boost packages from Debian unstable inside your pbuilder helps (if they're installable), so you might know if you need to get boost merged first
[13:04] <Laney> RAOF: I'll let you know if I find anything out
[13:04] <Laney> geser: Will do, thanks
[13:29] <luisbg> ahhhh
[13:30] <luisbg> oops, wrong window
[13:34] <Laney> RAOF: Debian bug #468061 looks promising. Building boost ATM to test.
[13:37] <norsetto> heya heya
[13:37] <persia> Hurrah!  norsetto's here.  Everything will now be done in the next six hours :)
[13:38] <gaspa> persia: are you still awake?
[13:38] <gaspa> :D
[13:38] <norsetto> persia: can I share your drink? Seems powerful
[13:38] <persia> gaspa: Yes.  I've a late meeting tonight.  Tuesdays and Thursdays are the days I'm most likely to be around late.
[13:39]  * gaspa write down this sentence..
[13:39] <gaspa> persia: about nbs. you said that packages.u.c isn't reliable for that. What should i use instead, in your opinion?
[13:41] <norsetto> gaspa: http://people.ubuntu.com/~ubuntu-archive/NBS/
[13:42] <persia> gaspa: The rmadison interface is fairly reliable.  If you can't get that to work, you could ask LP, but there's no good API.
[13:42] <gaspa> norsetto: yes, that's ok.... but i need sourcename, and some other infos.
[13:42] <gaspa> persia: ok, i'll take a look
[13:42] <persia> gaspa: You could also pull a packages file, but you'd need to pull for each architecture, which makes it a bit messy.
[13:42] <gaspa> i see.
[13:43] <persia> gaspa: Hmm.  Looking again, it seems that rmadison doesn't support ports.ubuntu.com.  If you could figure out how what is required, it'd be nifty (although only as an optional switch)
[13:46] <geser> what about the output of "apt-cache madison <pkg>"? it also lists the source package name (if one has a deb-src line)
[13:49] <gaspa> geser: I don't want to depend totally on local sources.list. apt-cache could be a first approach to speed up the process. but i need also a static place(like packages.u.c, but more updated) where get infos.
[13:50] <gaspa> for example, now, i do a local request to get sourcename, and if there isn't in apt-cache output, i fall back to packages.u.c
[13:52] <geser> gaspa: what about wget the Sources.gz from archive.u.c and use grep-dctrl on it? or do you want additional dependencies for the script neither?
[13:53] <gaspa> geser: not now... yes, it could be fine archive.u.c...
[13:54] <gaspa> at least i could try and see if it's not too slow.
[13:55] <geser> gaspa: as a.u.c is only updated hourly, you could refetch the Sources.gz only if they're missing or older than one hour
[13:57] <gaspa> well... the nbs get refreshed every 6 hours, so a more fine timing is pretty unusefull.
[14:04] <gaspa> geser, persia: just for curiosity, why 6 hours?
[14:05] <persia> gaspa: That's the cron configuration for the script that generates them.
[14:06] <norsetto> gaspa: whats your idea for the nbs?
[14:07] <gaspa> norsetto: using a inverse approach, looking the package that depends on them... 'cause they're the ones that  should be fixed.
[14:07] <gaspa> norsetto: http://iogaspa.altervista.org/nbs/reversenbs.xml
[14:09] <gaspa> persia: ok, i meant if there was a _particular_ reason... but don't mind. :) just curiosity
[14:10] <persia> gaspa: Well, it used to be when we bothered the maintainer, so it went into daily cron.  Then someone in Australia pointed out that running it at the beginning of the European workday wasn't ideal for their workflow, so it moved to 6 hours.
[14:10] <gaspa> :D
[14:10] <persia> If there are enough people chasing it quickly enough to justify more frequency, it could be arranged to be as often as hourly, but currently there isn't much value gained.
[14:11] <gaspa> i agree.
[14:15] <gaspa> norsetto: given your question, now i want feedback from you.
[14:16]  * norsetto gives feedback to gaspa
[14:17]  * gaspa gives thanks to norsetto
[14:21] <Laney> RAOF and geser: Updating to the sid version of boost fixed the FTBFS. Thanks for your help.
[14:21] <Laney> (I wonder if it's worth me doing the merge)
[14:22] <geser> Laney: IMHO it doesn't make much sense to sync vegastrike now if it's know it will FTBFS until boost gets merged
[14:22] <amikrop> If you package your Python application as a .deb package with debhelper, then you don't need a setup.py, right?
[14:23] <amikrop> I mean, packaging with debhelper makes setup.py (and distutils) obsolete?
[14:24] <geser> amikrop: not really, debhelper only helps you with common task during package building but it doesn't make distutils obsolete
[14:25] <amikrop> geser: How setup.py (distutils) could be combined with debhelper?
[14:25] <ScottK> amikrop: In your build rule call python setup.py build
[14:25] <geser> isn't calling setup.py the equivalent of make install for a C program?
[14:26] <ScottK> amikrop: In your install rule call python setup.py intall (and then there's an option to tell it where to install).
[14:26] <ScottK> geser: Pretty much.
[14:26] <persia> geser: Well, "setup.py build" is "make all", and "setup.py install" is "make install".
[14:26]  * persia notes that make does more than C
[14:26] <amikrop> ScottK, geser: Aha. Right.
[14:26] <geser> amikrop: if you don't need something special, package a python using distutils with cdbs should be quite easy
[14:27] <amikrop> I see.
[14:27] <ScottK> amikrop: If you want to use debhelper, stepic is a reasonable example.
[14:27] <amikrop> ScottK: What is "stepic"?
[14:28] <Laney> geser: I meant the boost merge
[14:28] <ScottK> amikrop: It's a python package that uses debhelper and distutils.  https://launchpad.net/ubuntu/+source/stepic
[14:29] <amikrop> ScottK: Cool, thanks.
[14:31] <amikrop> ScottK: Actually, how I get the whole dir (with debian/ inside)?
[14:32] <ScottK> apt-get source stepic or dget https://launchpad.net/ubuntu/hardy/+source/stepic/0.3-1/+files/stepic_0.3-1.dsc 0 I'd recommend the later if you don't have intrepid sources in your sources.list
[14:35] <amikrop> ScottK: Actually, if I apply the .diff to .orig.tar.gz will I have the result?
[14:36] <ScottK> If you have the source package and you want to unpack it, the best way to do it is dpkg-source -x filename.dsc
[14:36] <cyberix> What is the compat file for?
[14:37] <ScottK> I should have said dget -x above. That would have unpacked it too.
[14:37] <persia> cyberix: It specifies the lowest major version of debhelper with which the package is compatible
[14:37] <ScottK> cyberix: It says what Debian packaging compatibility level the package supports.  It's roughly equivalent to the major version number of debhelper needed to build the package.
[14:37] <nxvl> dholbach: i show your video on Friday before starting :D it was kewl
[14:38] <cyberix> So why isn't build-dep enough?
[14:38] <amikrop> ScottK: OK, thanks.
[14:39] <ScottK> cyberix: Because using debhelper isn't actually required.  Almost everyone does, but there are other ways to do it.
[14:40] <persia> cyberix: Also because you might build-dep on debhelper 6 for some specific feature, but still have your debian/rules in debhelper 4 format (assuming you are sufficiently lazy, or just doing a quick patch to a package)
[14:41] <POX_> .oO( ScottK is already in T&S )
[14:41] <ScottK> POX_: I have also had to work on Manoj's packages, so I know debhelper isn't a requirement.
[14:42] <POX_> :)
[14:48] <Kopfgeldjaeger> http://launchpadlibrarian.net/15377022/buildlog_ubuntu-intrepid-i386.multisync0.90_0.92.0~svn355-1_FAILEDTOBUILD.txt.gz  <-- looks like a Dependency problem, right? The package builds fine in my pbuilder so I guess it was a temporary problem
[14:49] <persia> Kopfgeldjaeger: Maybe.  Is your pbuilder up-to-date?
[14:49] <Kopfgeldjaeger> ok, in fact it doesn't work in my pbuilder
[14:49] <Kopfgeldjaeger> It worked before my pbuilder update... so there's a problem with an update
[14:53] <norsetto> POX_: thanks for uploading pyelemental again
[14:54] <POX_> norsetto: I've changed debian/copyright a little bit before uploading
[14:54] <norsetto> POX_: ok, I didn't see that
[15:10] <cyberix> I have no idea, if my package would work with debhelper earlier than 5
[15:15] <bddebian> Heya gang
[15:20] <geser> Hi bddebian
[15:21] <bddebian> Heya geser
[15:24] <norsetto> geser: Sie moechten Ihre Zeit fuer Ihr Vermoegen anwenden?
[15:24] <norsetto> geser: (no idea what that means)
[15:25]  * norsetto now also receives spam in german and russian
[15:26]  * jpds doesn't know the last two words in that sentence
[15:26] <apachelogger> actually that sentence is pretty wrong
[15:26] <Hobbsee> norsetto: they want to use your time for your fortune.
[15:26] <apachelogger> grammarwise
[15:27] <Hobbsee> apparently.
[15:27] <Hobbsee> apachelogger: that's what i thought, too.
[15:27] <norsetto> he, not only german spam, but also wrong german spam:-)
[15:27] <sebner> rofl
[15:28] <sebner> norsetto: show the wrong german spam :P
[15:28] <norsetto> well, I spare you all the rest of the email
[15:29] <sebner> norsetto: forwand it to me =)
[15:29] <apachelogger> hm
[15:29] <apachelogger> thinking about it
[15:29] <norsetto> sebner: you gonna get it anyhow, its spamming a whole bunch of ubuntu.com addresses
[15:29] <apachelogger> I think sebner is a mail address aggregator for spamm0rs :P
[15:30]  * sebner hides. they discovered his secret. He is the spamking and uses his adress/contacts to spam the whole world xD
[15:31] <cyberix> norsetto: I just fixed the issues in mi2svg
[15:31] <norsetto> cyberix: good, thanks
[15:32] <superm1> Riddell, its a codec wrapper
[15:32] <superm1> Riddell, like how wine is a windows binary loader
[15:32] <superm1> Riddell, the upstream website indicates it's GPL
[15:32] <superm1> Riddell, but its not in their .orig.tar.gz
[15:32] <superm1> it's on code.google.com
[15:32] <superm1> i filed a bug with them to include the GPL with orig.tar.gz
[15:33] <superm1> which should be documented in the debian/rules part that pulls it
[15:34] <cyberix> norsetto: no problem, please point out any further problems
[15:34] <superm1> Riddell, and that -dev package is intended to be built against.  after this gets pulled in i'll get patches set up appropriately for the other packages that can use it
[15:49] <directhex> superm1, you planning on patching myth et al with coreavc support then?
[15:49] <superm1> directhex, well i'm going to provide two libmyth-0.21's
[15:49] <superm1> one with coreavc support
[15:49] <superm1> one w/o
[15:49] <superm1> since upstream hasn't made it conditional to include it yet
[15:51] <superm1> the build process for doing it like this is a little annoying now
[15:51] <superm1> but i guess stuarta will have it as an option for 0.22
[16:14] <lukehasnoname_> join #freebsd
[16:14] <lukehasnoname_> er
[16:52] <Ekushey> i tried to upload a fonts package to my PPA, and i got the following message: Rejected: Unable to find distroseries: unstable
[16:53] <sebner> Ekushey: use intrepid instead of unstable in your changelog
[16:54] <wasabi> Trying to use dpkg triggers. Figured out that I need a packages .triggers file. However, where do I put the action for the trigger?
[16:54] <wasabi> in the postinst or preinst?
[16:56] <Ekushey> sebner, so i'll just have to replace unstable to intrepid and rebuild the package? is that all?
[16:56] <sebner> Ekushey: yep
[16:57] <Ekushey> thanks sebner
[16:58] <sebner> np
[17:27] <genii> Hello. I was here yesterday, getting some insight into the backport process. In this case pdfedit current version in 8.10 back to 8.04. It was suggested to compile the Intrepid sources with pbuilder and test. I have the sources but am not certain what arguments to pass to pbuilder at this point.
[17:32]  * genii puts on a pot of coffee
[17:33] <Laney> genii: You can build the intrepid version using prevu: https://wiki.ubuntu.com/Prevu
[17:34] <genii> Laney: For Hardy?
[17:34] <Laney> genii: Yeah
[17:34]  * genii reads the wiki
[17:44] <cody-somerville> How does prevu differ from using pbuilder?
[17:46] <genii> Hm. Prevu is giving me "/home/user.pbuilderrc does not exist"  ... will this cause any issue?
[17:46] <ScottK> genii: No.
[17:46] <genii> ScottK: OK
[17:46] <ScottK> cody-somerville: prevu is a simplified wrapper around pbuilder for non-developers to test backports.
[17:47] <ScottK> genii: That just means the default config in /etc gets used.
[17:50] <sebner> !prevu =)
[17:50] <sebner> !prevu
[17:50] <sebner> ha
[17:50] <genii> If I have already a deb-src for Intrepid in my sources will it get confused?
[17:52] <ScottK> It shouldn't.
[17:53] <genii> OK
[17:55] <\sh> moins ScottK
[17:56] <ScottK> heya \sh.
[18:10] <wasabi> So how in the world do I accomplish this:  binary packageA in a source package containing 10 packages needs to be triggered when any of the other binary packages change.
[18:10] <wasabi> I've created debian/triggers, and set it to activate foo-update
[18:10] <wasabi> and debian/packagea.triggers, and insured it was set to interest foo-update
[18:11] <wasabi> And implemented code in packagea.postinst that detects if $1 is triggered, and does work.
[18:11] <wasabi> The code in packagea is never executed, as far as I can tell, and nothing even tries to make it be.
[18:12] <wasabi> And even if I slap it around enouhg, it does evenentually run the triggers.... but BEFORE some dependcies have been set up
[18:14] <Ekushey> when i try to apt-get install a package that i built, i get the "WARNING: The following packages cannot be authenticated!" message. how do i remove it?
[18:16] <directhex> Ekushey, have a signed repository, e.g. don't try to access your PPA directly
[18:17] <Ekushey> directhex, i'm very new to this, this is the first package that i uploaded to my PPA
[18:18] <Ekushey> downloading anything from PPA will give this warning?
[18:18] <directhex> Ekushey, PPA archives aren't signed. you need to mirror them elsewhere (and sign them in the process) to avoid the problem
[18:20] <Ekushey> ok, thanks... i need to study more about it
[18:49] <Ekushey> is there a way i can delete the amd64 build of a package from my PPA?
[18:50] <directhex> i don't think so. you can delete the entire source package & all binaries, though
[18:54] <Ekushey> directhex, so what i can do is change "Architecture: any" to "Architecture: i368" on the control file, rebuild and reupload to PPA?
[18:56] <directhex> yeah, that'd work. why're you hatin' on amd64 though? do real people really use i386 in this day & age?
[18:57] <Ekushey> directhex, this is the actual problem: https://launchpad.net/~ubuntu-bd/+archive/+builds?build_text=&build_state=failed
[18:58] <Ekushey> amd64 and lpia build failed, only i386 build worked
[18:58] <directhex> why is a font architecturey? O_o
[18:58] <directhex> surely ttf files are arch independent?
[18:59] <Ekushey> should be :)
[19:00] <directhex> "any" and "all" aren't the same thing
[19:00] <laga> shouldn't it say "Architecture: all" so it's arch-independent?
[19:00] <laga> yeah
[19:00] <directhex> "all" means a single _all.deb
[19:00] <directhex> "any" means a _i386.deb, _amd64.deb, _arm.deb and so on
[19:00] <Ekushey> oh... so that is the mistake that i did
[19:01] <Ekushey> i'm rebuilding it then
[19:01] <Ekushey> should i delete the current package from my ppa, or will it update itself when i reupload
[19:02]  * Ekushey is a 1-day old packager ;)
[19:02] <ScottK> Increment the revision number and upload again will take care of it.
[19:03] <Ekushey> ScottK, i add it on the changelog?
[19:04] <ScottK> Yes.  Add a new debian/changelog entry with a higher revision number.
[19:04] <ScottK> Use dch -i to get the initial template for the entry.
[19:09] <Ekushey> ScottK, the version number was 0.1-1, the new one is 0.1-1ubuntu1. is that OK?
[19:10] <ScottK> Ekushey: I'd suggest 0.1-1ubuntu1~ppa1
[19:10] <ScottK> That way you can increment as needed (the ppaX part) without affecting 'real' revision numbers.
[19:11] <Ekushey> alright, thanks!
[19:12] <directhex> i'd suggest something alphabetically earlier than "ppa"
[19:13] <directhex> if you're building packages against hardy, then you want something alphabetically earlier than "hardy", to ensure official backport packages will supercede your ppa (e.g. an official backport of foopackage 0.3-2ubuntu1 to hardy will be numbered 0.3-2ubuntu1~hardy1)
[19:15] <Ekushey> directhex, so what should i put?
[19:15] <Ekushey> is there any wikipage explaining the versioning issues?
[19:15]  * ScottK agrees with directhex actually.
[19:16] <ScottK> I actually use Xubuntu1~release1~ppa1
[19:16] <ScottK> Not a simple one.
[19:18] <Ekushey> so i should make it like 0.1-1ubuntu1~hardy1~ppa1?
[19:19] <ScottK> Yes.  That's better than my initial suggestion.
[19:20] <mario_limonciell> well it really depends on when you intend the package to be in use i think
[19:21] <Ekushey> alright, reuploading :)
[19:21] <mario_limonciell> there are cases that you wouldn't want the backport to supercede your PPA
[19:21] <mario_limonciell> say if you were putting in a patch that wouldn't ever show up in a backport necessarily
[19:21] <YokoZar> Hooray, Wine 1.0 in intrepid now
[19:21] <YokoZar> Now...what's the process for getting it into hardy backports?
[19:22] <mario_limonciell> YokoZar, are you the person regularly working on getting wine in Ubuntu?
[19:22] <mario_limonciell> if so, i've got a question for you
[19:22] <YokoZar> mario_limonciell: Yes I am
[19:23] <mario_limonciell> YokoZar, coreavc is leveraging some code from wine from the looks of it.  I'm not sure how old the code is, but it currently fails on amd64.  I was wondering if you glanced over the build log if the failures look similar to old wine failures on amd64 to you.  If so, then I can try to update the code in there and resubmit it upstream to the coreavc project
[19:23] <mario_limonciell> http://launchpadlibrarian.net/15342144/buildlog_ubuntu-hardy-amd64.coreavc_0.1~svn63-0ubuntu1~ppa1_FAILEDTOBUILD.txt.gz
[19:26] <mario_limonciell> YokoZar, regarding your question though, files a bug against the hardy-backports project on launchpad
[19:27] <YokoZar> mario_limonciell: Yeah I just found that part on the wiki :)
[19:27]  * YokoZar looks at build log
[19:30] <YokoZar> mario_limonciell: I'm a bit curious as to what kind of code it is.  Wine only builds experimentally in 64-bit mode; the amd64 package is built by compiling in 32 bit mode and linking with 32 bit libraries (mostly in ia32-libs)
[19:30] <mario_limonciell> YokoZar, oh, i had thought that wine had started to build in 64 bit mode stably since it was showing up on amd64.  That answers the question
[19:30] <mario_limonciell> i'll have to add in a similar workaround for this then for now
[19:31] <mario_limonciell> YokoZar, if you are curious to look over the code, its sitting in intrepid NEW right now or on the ~mythbuntu PPA
[19:34] <sistpoty> hi folks
[19:35] <geser> Hi sistpoty
[19:35] <sistpoty> hi geser
[19:36]  * lukehasnoname hi
[19:37] <bddebian> Heya sistpoty
[19:37] <sistpoty> hi bddebian
[19:43] <norsetto> hi sistpoty
[19:43] <sistpoty> hi norsetto
[19:43] <sistpoty> norsetto: doko merged atlas yesterday \o/
[19:44] <norsetto> sistpoty: \o/ alleluja!
[19:48] <norsetto> sistpoty: argh, still fails on i386
[19:48] <sistpoty> :(
[19:48] <cyberix> norsetto: Did you check my changes?
[19:48] <norsetto> cyberix: no
[19:49] <cyberix> norsetto: Should I encourage sistpoty to look at it or do you still want to complain :-D
[19:49] <cyberix> Well revu day comming tomorrow
[19:49] <cyberix> I could also ask some third guy, if you are getting tired with the package :-)
[19:49] <norsetto> cyberix: is there anything left to complain about!?
[19:50] <cyberix> Well I think fixed everything you brought up so far
[20:14] <medo> hello
[20:15] <medo> I used apt-get into chroot in intrepid and I got exit with error code one.
[20:15] <medo> does that mean my setting for the chroot is wrong
[20:15] <medo> I have followed the steps exactly as in the wiki
[20:15] <geser> medo: what kind of error?
[20:16] <medo> syntax error
[20:16] <medo> in file statoverride
[20:17] <medo> I couldn't file this file anywhere
[20:17] <medo> ??
[20:17] <cyberix> How do you package software that expects to find all it's files in the same directory?
[20:17] <medo> this is the exact output I get "dpkg: syntax error: unknown group `Debian-exim' in statoverride file"
[20:18] <geser> cyberix: would a wrapper work, which cd into the correct dir and calls then the real binary?
[20:18] <cyberix> I suppose it is not hard to make it work
[20:18] <cyberix> I'm just wondering how this fits in with rest of the system
[20:20] <medo> geser: I'm using to install apt-utils so I can use apt-get -install after that
[20:20] <medo> I'm not sure if this would help though
[20:21] <pochu> any lists.tauware.de admin around?
[20:22] <Laney> geser: Do you have any objection to me merging gtkglarea and/or guidedog?
[20:24] <geser> Laney: no, as I don't have time to do merges myself, all my open merges are free to take (but a notification would be nice to know that someone is working on it)
[20:24] <Laney> geser: Ah, that's good to know. I always put a comment on DaD anyway so you'll know if I pick one up.
[20:24] <lukehasnoname> Will Gnome 2.24 make it into Intrepid? It's due out mid Sept.
[20:25] <geser> lukehasnoname: yes, at least it was so in the past that the current gnome version made it into the soon to be released Ubuntu version
[20:26] <geser> lukehasnoname: interpid has already the first gnome 2.23 devel packages
[20:27] <medo> geser: thanks a lot I figured it out. I misconfigured the file
[20:40] <pochu> sistpoty: do you have admin access to mailman on tauware.de? I have issues unsubscribing from a list
[20:42] <norsetto> cyberix: there is something funky with your translations
[20:43] <pochu> hey norsetto, how are you?
[20:44] <norsetto> Hola pochu!
[20:45] <pochu> sistpoty: I'm leaving for dinner, if you are an admin, could you see if there's still any 'pochu@' or 'pochu27@' address subscribed? I unsubscribed @ubuntu address but keep receiving mail... TIA!
[20:47] <sistpoty> pochu: sorry, don't have access to the list... siretart ^^?
[20:47] <sistpoty> pochu: (or you could ask on #ubuntuwire)
[20:48] <Mez> anyone know any good debconf tutorials
[21:19] <pochu> sistpoty: ok, thanks, I'll ask there
[21:33] <mathiaz> Mez: try http://www.fifi.org/doc/debconf-doc/tutorial.html
[21:33] <Mez> mathiaz, thanks - thats the one I found
[21:35] <siretart> pochu: the mailman on tauware will be shut down soon
[21:45] <pochu> siretart: and that list moved to ubuntuwire?
[21:45] <pochu> siretart: if so, will you keep the subscribers list?
[21:49] <siretart> pochu: yes, I copied the complete config over to ubuntuwire
[21:49] <siretart> including subscriptopns
[21:51] <pochu> siretart: ok, I'll keep an eye on it to see if I still have some issues. Thanks for your help
[22:02] <norsetto> good night all
[22:02] <jpds> g'night nor...
[22:02] <LinuxMonkey> night nand
[22:02] <LinuxMonkey> bah
[22:02] <jpds> hehe
[22:02] <LinuxMonkey> he left before i could tab it
[22:02]  * jpds hugs LinuxMonkey
[22:02] <LinuxMonkey> thanks ill need it
[22:03] <LinuxMonkey> im ready to pull some hairs
[22:03] <jpds> LinuxMonkey: I don't recommend that. You might need them later..
[22:04] <LinuxMonkey> true. trying to understand packages, how to fix my chroot to have my pgp keys and more.lol
[22:05] <ScottK> LinuxMonkey: Why do you need keys in your chroot?
[22:06] <LinuxMonkey> dunno im trying to follow the outdated guides in the wiki
[22:07] <Falken> Hi ! France is out of the Euro2008. Too bad :( Meanwhile, I have my first package (ever) waiting for reviews ... Can I do something to make things go faster ?
[22:08] <ScottK> LinuxMonkey: What wiki?
[22:08] <ScottK> Falken: You're more likely to get satisfaction if you give us a link to the package on REVU.
[22:10] <Falken> of course. http://revu.ubuntuwire.com/details.py?package=flabber
[22:10] <LinuxMonkey> ScottK its probably just me... probably didnt setup intrepid correctly.lol
[22:11] <LinuxMonkey> ScottK: Could not find a signing program (pgp or gpg)!
[22:11] <ScottK> LinuxMonkey: There's no need to sign inside a chroot.
[22:12] <ScottK> You should build (and sign) your source packages and then build them in a clean environment using pbuilder, sbuild, or similar.
[22:13] <LinuxMonkey> well im lost then, the guides are out of date, ill have to wait and see then, cause i really want learn this
[22:14] <sistpoty> ember: around? (I'm just looking at bug #237348)
[22:14] <ScottK> LinuxMonkey: What guide are you following?
[22:14] <LinuxMonkey> ScottK: https://wiki.ubuntu.com/PackagingGuide/Complete
[22:15] <YokoZar> Does anyone have a Gutsy and Feisty machine around to do a real quick test for me?
[22:16] <ScottK> YokoZar: Does it need to have X on it?
[22:16] <ScottK> LinuxMonkey: I don't see on that wiki where it says to sign stuff inside a chroot.
[22:16] <YokoZar> ScottK: Just want to see if the Wine package is installable, I imagine you dont
[22:17] <YokoZar> ScottK: https://edge.launchpad.net/~ubuntu-wine/+archive
[22:17] <ajmitch> YokoZar: making 1.0 available for us mortals?
[22:17] <YokoZar> I made a small change to debian/rules that I'm not certain the build daemon would barf on (ie it might be depending on a version later than what's available in gutsy)
[22:17] <ScottK> YokoZar: I'd just do that in a chroot then if I were you (pbuilder login).
[22:17] <YokoZar> ScottK: Yeah I didn't set up pbuilder yet, heh
[22:18] <YokoZar> I just use the ppa to build now
[22:18] <YokoZar> This is the last gutsy/older package for me at the moment
[22:18] <sistpoty> ajmitch: you just want it to play WoW, don't you? :P
[22:19] <LinuxMonkey> lol i allready play wow on here.lol
[22:19] <ajmitch> sistpoty: of course
[22:19] <sistpoty> heh
[22:19] <YokoZar> ajmitch: by the way, if you'd like to make 1.0 available to more mortals: https://bugs.edge.launchpad.net/hardy-backports/+bug/240755
[22:20] <LinuxMonkey> ScottK: ok well i guess im lost and probably followed that guide all wrong.lol
[22:20] <RainCT> If I want to backport a package that needs the cmake version from Intrepid, can I request a backport for both?
[22:20] <ajmitch> YokoZar: however I'm not in any backports team :)
[22:21] <YokoZar> ajmitch: still needs a confirm/triage (ie, build and test it)
[22:21] <ScottK> RainCT: You can request it, but what affect would that have on other packages?
[22:21] <RainCT> ScottK: that's why I ask :)
[22:21] <YokoZar> RainCT: cmake is a build tool used by other packages right?
[22:21] <YokoZar> It's unlikely it'd be backported in that case
[22:22] <ScottK> RainCT: I'd suggest teaching the package to work with the older cmake.
[22:22] <ajmitch> though cmake may be backwards compatible, backporting it may actually be safe
[22:22] <Laney> Is SHELL=/bin/bash allowed in a rules file?
[22:22] <ajmitch> unlike tools like automake with its 20 different versions
[22:22] <ScottK> That's probably require more testing than RainCT wants to do to confirm though.
[22:23] <sistpoty> Laney: yes... debian/rules is a makefile and SHELL=something that's the shell to be called from make to something
[22:23] <RainCT> well, I'll ask upstream (who asked me for the backport, although I don't know them :P) if they are happy with having it in a PPA (or if they want to get it working with cmake from hardy)
[22:23] <sistpoty> s/that's/sets/
[22:23] <jpds> RainCT: I suggest building the whole of KDE4, just to make sure it's safe to backport
[22:23] <RainCT> thanks guys :)
[22:23] <Laney> sistpoty: Right, thanks. I just didn't know if it had to remain as dash or anything
[22:24] <sistpoty> Laney: no, you don't as bash is in essential (if you'd use a custom shell not in (build)-essential, it'd need to be in build-depends though)
[22:24] <Laney> Got it :)
[22:25] <sistpoty> Laney: you might get extra points to eleminate bashism in debian/rules though (but if unsure, shell=/bin/bash seems like the most defensive solution though)
[22:26] <Laney> sistpoty: Nah, I'll not bother. I'm looking into whether do do a sync or merge, and leaving it as bash lets me do a sync so it's best to keep it as is.
[22:28] <ScottK> Laney: Switching to dash is a Debian release goal, so if you can resolve the bashism, it'd be a useful patch for Debian too.
[22:29] <ScottK> Without knowing how hard it is, I'd suggest fixing it to use dash and then filing a bug/patch with Debian.
[22:30] <Laney> ScottK: Someone already sent a fixed (to use dash) rules file to a bug on the BTS as there was an error with the bash version, but he chose to just fix the bug and keep it on bash. So there is a patch already.
[22:34] <sistpoty> ScottK: there's no bashism, if SHELL=/bin/bash ;)
[22:34] <ScottK> sistpoty: That just makes the bashism work.
[22:34] <sistpoty> or rather its completely allowed to use a bashism then
[22:34] <sistpoty> heh
[22:34] <ScottK> Sure, but it's still not idea.
[22:34] <ScottK> idea/ideal
[22:35] <sistpoty> hm... not too sure. for debian alone, it's not much of a big deal. as upstream who deals with building on other unices (like *bsd) as well, there is (as bash != bash there :()
[22:36] <Laney> Is this enough of a deal to stop me requesting a sync?
[22:36] <Laney> (Given that the maintainer is aware)
[22:36] <sistpoty> Laney: imo no, but you could still write a patch and forward it to DBTS ;)
[22:37] <Laney> sistpoty: It already exists, as I said above!
[22:37] <Laney> I'd give you a link but the bts isn't responding for me atm
[22:37] <sistpoty> Laney: heh, then just request a sync
[22:38] <Laney> sistpoty: Good, I will
[22:38] <Laney> Thanks :)
[22:38] <sistpoty> np
[22:40] <Laney> So while I wait for that to testbuild, can someone shed some light on why bug #181225 was invalidated? It seems sensible to me.
[22:40] <bobbo> can someone post their output of "sudo apt-get build-dep audacious" quickly?
[22:42] <Laney> bobbo: On Hardy?
[22:43] <bobbo> Laney: yeah
[22:43] <i4x> hugs 4 every1!!
[22:43] <Laney> bobbo: See notice!
[22:43] <sistpoty> Laney: seems to be some fallout of the Kmos debate back then... you might want to check if it's still valid or not
[22:44] <Laney> sistpoty: It is
[22:44] <sistpoty> Laney: then go and set it back to a sane state ;)
[22:44] <Laney> Righto
[22:58] <ScottK> \sh: I hope you're OK with the latest claws-mail upload.
[23:06] <bdmurray> I'm curious if something is packagable.  I'm uncertain about the firmware parts involved.
[23:07] <bdmurray> It's the R5u870 driver.
[23:08] <ScottK> Do you have a link to the relevant license text?
[23:08] <ScottK> bdmurray: ^^^
[23:10] <bdmurray> ScottK: the tarball is linked to at http://wiki.mediati.org/Installation
[23:14] <sistpoty> bdmurray: ugh, the firmware seems to be extracted right out of the windows driver, so I doubt it's easily redistributable
[23:14] <sistpoty> bdmurray: at least not via GPL as advertised in COPYING
[23:14] <bdmurray> sistpoty: Okay, that is what I had thought but wasn't certain.
[23:15] <ScottK> sistpoty: Copied or reverse engineered?
[23:18] <bdmurray> It looks like it might be possible to reverse engineer it
[23:19] <bdmurray> Oh, maybe not.
[23:20] <sistpoty> ScottK, bdmurray: according to recode-fw.scm extracted from the windows driver
[23:20] <sistpoty> (nontheless, even if reverse engenieered, it would lack the source code for gpl-2)
[23:23] <sistpoty> bdmurray: however it might be possible if the firmware could be shipped separately (or downloaded by maintainer scripts) from the driver
[23:24] <ScottK> However I'd be reluctant to do that with something that claimed to be GPL, but wasn't on the face of it.
[23:25] <bdmurray> There is a launchpad bug report, if we could get to it ;-), about this particular driver and packaging it.
[23:26]  * ScottK suggests invalid as an appropriate status.
[23:28] <bdmurray> Maybe "Won't Fix" because of the current way it stands?
[23:28] <sistpoty> ScottK: well, the driver itself looks fine (at least each file has gpl headers). The only problem I see is that the firmware would need to get downloaded and extracted from the windows driver on package install (or by a package in multiverse, depending on the license of the windows driver)
[23:39]  * sistpoty goes to bed... gn8 everyone


[09:14] <janv_> Hello all
[09:16] <janv_> I'm using Ubuntu 13.04 - and would like to use the owncloud-client
[09:16] <janv_> I could not find this client in the Ubuntu repositories, nor is it provided at: http://owncloud.org/sync-clients/
[09:16] <janv_> Should I add a bug report to request for the owncloud Desktop Sync Client?
[09:20] <rbasak> Is the owncloud Desktop Sync Client free software?
[09:23] <rbasak> Looks like it's in Debian, so it presumably is. Ubuntu has a delta, too. So I think it would be reasonable to file wishlist bugs against it.
[09:27] <janv_> ok, thanks. I will do so.
[09:38] <janv_> rbasak: for your info, the license is stated here: https://github.com/owncloud/mirall#readme
[09:38] <janv_> GPLV2 or later
[15:24] <Str8bs> Hi. Bug affects me vs. dupes ?
[15:24] <Str8bs> Wiki indicates "one person per issue per hardware" https://help.ubuntu.com/community/ReportingBugs
[15:25] <Str8bs> I see frequent mailing list notes requesting please click on "this bug affects me."
[15:25] <Str8bs> Which is appropriate? I'm confused. :)
[15:30] <hggdh> Str8bs: sort of both of them. For kernel issues, it is better for a new bug to be opened, since very small hardware differences may impact; for anything that does not directly deal with hardware, "also affects me" is the way to go
[15:31] <hggdh> Str8bs: usually, what we worry about is *one* bug report reporting *many* bugs -- this is certainly NOT the way to go
[15:32] <Str8bs> hggdh: Thanks. I spend a lot of time obsessing over open source drivers. That would fall under hardware.
[15:32] <Str8bs> I "think" I get it now. :)
[15:33] <hggdh> Str8bs: also, please note that the rule is actually "one report, per person, per hardware combination, per bug"
[15:33] <hggdh> so, if the hardware is the same, "also affects me" applies :-)
[15:34] <hggdh> Str8bs: please do not hesitate in asking your questions about bug work here -- we strive to help, and all that :-)
[15:35] <Str8bs> hggdh: I've reached out to ubuntu-x for some pointers on graphics drivers. Trying to clarify some ongoing KMS graphics issues on PPC.
[15:35] <Str8bs> As long as I follow code of conduct, OK to try to request logs/ mark dupes/ mark incomplete without offending anyone?
[15:35] <hggdh> Str8bs: yeah, I would guess they will be more of experts on graphics...
[15:36] <hggdh> Str8bs: yes, of course. We *need* help in triaging the bugs. Too few triagers, too many bugs
[15:37] <Str8bs> hggdh: Thanks. I'm still new at Linux and just want to make sure I don't overstep my bounds.
[15:38] <Str8bs> I'm sure someone will point out my mistakes. :)
[15:39] <hggdh> Str8bs: we will, please rest assured. But we will be nice, and also point you to better ways ;-)
[15:41] <hggdh> Str8bs: this might also help you: http://wiki.ubuntu.com/DebuggingProcedures
[15:42] <Str8bs> hggdh: I will start trying to help out. Thanks again!
[15:42] <hggdh> and https://wiki.ubuntu.com/BugSquad
[15:42] <hggdh> Str8bs: actually, thank YOU. We do appreciate the help!


[18:48] <mpmc> O.O - OK so I added a cputemp to the top bar. Now I see the "budgie panel" in plank, it wasn't there before!
[19:20] <cdw3> Is there a way to add scripts and apps I develop to my launcher?
[19:20] <cdw3> I'm new to the Budgie desktop.
[21:44] <fossfreedom> mpmc, what distro version - 16.04 or 17.04?  logoff - logon.  This is something I'm aware of that was fixed in 17.10 but I need to find sometime to backport to 16.04/17.04
[21:45] <mpmc> fossfreedom: "$ cat /etc/issue -> Ubuntu 17.10"
[21:46] <fossfreedom> huh? ok something else - picture?
[21:46] <mpmc> fossfreedom: Also for some reason I'm now getting a grub menu, but it's showing strings for 16.04.
[21:46] <fossfreedom> one thing at a time
[21:50] <mpmc> fossfreedom: Sorry, :p https://i.imgur.com/E7EmtAP.jpg
[21:51] <fossfreedom> when does "budgie panel" appear?
[21:52] <mpmc> After I modified the panel, it disappears if I log out.
[21:52] <mpmc> by modify I mean add {cputemp}.
[21:52] <fossfreedom> does it appear as soon as you open "budgie settings" ?
[21:54] <mpmc> fossfreedom: No, when I open the preferences menu from the panel (right clicking the monitor text).
[21:55] <mpmc> Sorry, left clicking >.<
[21:55] <fossfreedom> hmm - ok - please file a bug against this project - https://github.com/fossfreedom/indicator-sysmonitor
[21:55] <fossfreedom> I'll try to reproduce this later
[21:56] <mpmc> Ok.
[22:01] <mpmc> fossfreedom: OK done [https://github.com/fossfreedom/indicator-sysmonitor/issues/78]
[22:02] <fossfreedom> thanks
[23:31] <Guest14002> Hi. New Budgie user. I was wondering if the ubuntu 17.10 issue of corrupting the bios of certain manufacturers is present with budgie 17.10. Thanks.
[23:33] <Guest14002> I was referring to Bug #1734147 described at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147


[00:43] <xnox> plars: balloons: there is a new nexus7 dock that supports charging via pongs while keeping the usb-port free...... =)
[00:44] <xnox> pongs being the connection points on the left sides, bottom.
[00:47] <xnox> https://plus.google.com/112773496741623034196/posts/9iyD4fC688i
[01:19] <plars> xnox: it's about time
[01:20] <xnox> plars: i guess they'll be sold out rather quickly, just like the nexus4 bumpers.
[01:20] <xnox> pgraner: ^^^^ do we want / need charging docks for nexus7/qalab =)
[01:21] <plars> xnox: unfortunately while helping with some problems, it doesn't help with others. But those are getting worked on and a lot are already resolved
[01:21] <xnox> plars: fair enough ;-)
[01:22] <plars> xnox: the price is not bad on them, though I do wonder how stable the connection is. The pogo pins seem very susceptible to being bumped
[01:22] <plars> tablet slides sideways by 1mm in the dock, and no more power
[01:22] <plars> I wonder how securely it holds it
[01:35] <xnox> *sigh*
[05:50] <pitti> Good morning
[07:45] <dholbach> good morning
[07:45] <pitti> hey dholbach
[07:45] <dholbach> hi pitti
[09:24] <vibhav> good morning
[09:30] <zyga> good morning
[12:17] <xnox> psivaa: have you noticed any other bugs with webcam step?
[12:17] <xnox> psivaa: why is removal of webcam step linked to results in the iso-tracker?
[12:18] <xnox> (this is a pure design / ubiquity restructuring planning and not driven by "bugs" / "brokeness" of the webcam step)
[12:19] <psivaa> xnox: well i added it to the tracker because at the moment the webcam does not work during the installation. That being in the tracker would stop bugs like, 1142751
[12:19] <psivaa> bug 1142751
[12:20] <xnox> psivaa: that's an over-generalisation. That's only one personal reporting visual corruption on the view port with an unknown webcam without any installer logs attached.
[12:21] <xnox> psivaa: you should link bug 1142751 to the isotracker, not the "wishlist requests to remove webcam step".
[12:22] <xnox> psivaa: the webcam step certainly works locally here for me in ubiquity, on my machines. But I fear if this is a bug/regression in the underlying gstreamer library.
[12:22] <psivaa> xnox: ohh ok, will any webcam related bugs fixed for raring?
[12:23] <xnox> psivaa: we should be undressing them, yes. Without further investigation, it's hard to tell if it's a general webcam bugs in our stack vs ubiquity-specific webcam bug.
[12:23] <xnox> And we do want webcams to work on ubuntu. Hangouts, video chat etc are very mainstream =)
[12:27] <psivaa> xnox: ok, theses bugs are only during installation but ok ill see if the wishlist bug could be removed from the tracker
[12:40] <xnox> psivaa: yeah, it doesn't fail the install or anything like that, but it does exercise our gstreamer stack fairy well =)
[12:41] <xnox> s/fairy/fairly/ =)
[13:58] <psivaa> xnox: ok sorry about that :), it appears stgraber is one that could remove it
[13:58] <xnox> psivaa: yeah, he can do anything on that website =)
[13:59] <psivaa> stgraber: would you be able to remove bug 1118589 from the iso tracker please?
[14:20] <stgraber> psivaa: done
[14:20] <psivaa> stgraber: thank you
[14:21] <psivaa> xnox: ^ and I have removed the tag from the bug
[14:21] <xnox> \o/ thank you guys =)
[14:22] <xnox> psivaa: and it's a real bug in clutter-gst shaders which me and Laney are working to fix.
[14:22] <psivaa> xnox: ok, thanks for that
[15:12] <zyga> spineau: do you want to keep checking your network to see why vagrant up failed for you?
[15:13] <spineau> zyga: that would be cool but I don't really see a log entry to start debugging the issue
[15:16] <zyga> spineau: ok, I think I know how to quickly check this
[15:16] <zyga> spineau: unset VAGRANT_APT_CACHE
[15:16] <zyga> spineau: vagrant destroy -f
[15:16] <zyga> spineau: vagrant up precise
[15:17] <zyga> spineau: then tell me if you see apt-get errors again or do you see slow but normal package installs
[15:17] <zyga> er
[15:17] <zyga> no, that's correct
[15:21] <SergioMeneses> morning!
[15:25] <balloons> SergioMeneses, hello
[15:27] <zyga> spineau, brendand, roadmr: I'm going to land the vagrant fix and see what of the currently approved set can land
[15:28] <spineau> zyga: sure
[15:30] <smartboyhw> Hiyas
[15:31] <smartboyhw> balloons ^
[15:32] <balloons> smartboyhw, ;-p
[15:32] <balloons> so cadence week 8 is going to be starting up..
[15:32] <smartboyhw> yep
[15:32]  * balloons rattles head
[15:33] <smartboyhw> lol
[15:33] <balloons> as usual, I'm open to discussions on what to include
[15:33] <balloons> so, SergioMeneses, smartboyhw , thoughts?
[15:33] <smartboyhw> KDE?
[15:33] <balloons> If possible there are some new tests I'd like to push into the cadence
[15:34] <balloons> We need the upgrade (from image) test to be finished
[15:35] <zyga> spineau, roadmr, brendand: tarmac started, the order of merges is random, I cannot improve that -- if it fails I'll re-approve the proposals that get borked
[15:35] <zyga> oh, the right branch is first, cool
[15:37] <SergioMeneses> balloons, thoughts about what?
[15:38]  * SergioMeneses is reading The Planet
[15:38] <balloons> SergioMeneses, yes, lots of reviewing and reading
[15:38] <balloons> :-p
[15:38] <balloons> SergioMeneses, thoughts on what to look at for cadence week 8
[15:39] <smartboyhw> balloons upgrade tests are good
[15:39] <SergioMeneses> mmm....
[15:39] <SergioMeneses> daily testing
[15:40] <smartboyhw> SergioMeneses: Laptop testing?0
[15:40] <smartboyhw> We need applications tests....
[15:41] <SergioMeneses> smartboyhw, yes, we need more testcases and make testing
[15:41] <SergioMeneses> http://packages.qa.ubuntu.com/qatracker/milestones/258/builds
[15:42] <smartboyhw> hmm what to do?
[15:42]  * smartboyhw might have to finish his Transmission testcase tmr
[15:42] <SergioMeneses> smartboyhw, I hope so
[15:42]  * SergioMeneses hides
[15:43] <smartboyhw> balloons: autopilot?
[15:43] <smartboyhw> Or flavour images testing?
[15:43] <balloons> smartboyhw, yes new app tests would be great
[15:43] <smartboyhw> Or???????????????????????????????
[15:44] <SergioMeneses> autopilot again?
[15:44] <smartboyhw> lol
[15:44] <balloons> mm.. probably not autopilot, as we're close on some cool things, but not ready yet
[15:44] <SergioMeneses> do we have more features?
[15:44] <SergioMeneses> ok
[15:44] <smartboyhw> balloons what are the cool things!?!?!?
[15:45] <balloons> converting everything to introspection.. but the coolest is using umockdev.. what it allows is to create fake hardware (by using real hw) to test things that need it
[15:45] <smartboyhw> wow
[15:45] <SergioMeneses> :O
[15:45] <balloons> for instance, testing shotwell.. and having a virtual camera to go with it :-)
[15:45] <smartboyhw> XD
[15:46] <balloons> carla has been working on it for a bit..
[15:46] <smartboyhw> I want that now!!!!!!!!!!!!!!!!!!!!!!
[15:46] <smartboyhw> balloons, great letozaf_ (Carla's nick right?*
[15:47] <balloons> I'd also like to continue the bug confirmation idea we did last time
[15:47] <smartboyhw> balloons uh
[15:47] <balloons> I've not yet gone to look and see if we managed to shrink the open ubiquity stuff
[15:47] <balloons> I'd like us to go after open issues we've found during the cycle
[15:48] <smartboyhw> balloons how about VirtualBox? Fixed?
[15:48] <zyga> woot, tarmac lands checkbox fix for CI loop based on vagrant
[15:48] <balloons> smartboyhw, u mean testdrive + vbox?
[15:48] <balloons> if so, yes, yes it is :-)
[15:48]  * xnox ponders if umockdev can fake hard-drives.
[15:49] <smartboyhw> balloons good
[15:49]  * zyga thinks that mocking is great but setting up real hardware is better for actual resutls
[15:49] <SergioMeneses> balloons, can we add ubuntu-friendly to our cadence wee someday?
[15:49] <SergioMeneses> *week
[15:49] <zyga> especially for performance regressions and quirks/odd hardware that you can just plug to an existing system overnight
[15:50] <smartboyhw> SergioMeneses of course.b.
[15:50] <balloons> xnox, I was thinking about exotic hardware as well.. disk controllers, tv tuners, etc
[15:51] <SergioMeneses> i think it would interesting and we can spreading UF a lot!
[15:51] <balloons> SergioMeneses, certainly we can have uf be a part.. atm, using the laptop tracker to test hw is better (so we do that instead) for ensuring we get the results
[15:51] <smartboyhw> balloons: For TV tuners contact the Mythbuntu.
[15:52] <smartboyhw> team
[15:52] <balloons> smartboyhw, :-) At one point I was interested.. I don't watch tv anymore
[15:52] <smartboyhw> balloons whoa?!!!!???!??!?!?!
[15:55] <balloons> smartboyhw, lol.. scary eh?  haven't for years.. I gave away the tv i inherited last year after never plugging it in
[15:55] <balloons> xnox, whoa -- there's an xchat-indicator? http://blog.surgut.co.uk/2013/02/x-chat-power-user-upload.html
[15:56] <SergioMeneses> balloons, watch tv on the laptop
[15:56] <balloons> SergioMeneses, yes.. in many ways, that's where we are at.. anyways, back to reality :-)
[15:58] <smartboyhw> Back
[15:58] <SergioMeneses> smartboyhw, ++
[15:58] <smartboyhw> SergioMeneses, ?
[16:01] <SergioMeneses> smartboyhw, you're back! anyway balloons can we publish something official about testing in the UGJ? I see "the planet" and cry
[16:01] <balloons> SergioMeneses, yes, I am working on some communication from me personally, and of course some words about quality and what we're doing
[16:01] <smartboyhw> SergioMeneses we might need to.
[16:02] <balloons> in short, nothing changes at the moment for us.. we discussed how we would work in a rolling world, and we know how we operate now..
[16:02] <smartboyhw> balloons: how?
[16:02] <balloons> I don't want to diatribe too much here.. but if they change focus towards faster cadences, we know how to do that..
[16:03] <balloons> we don't want to be overwhelmed with things however
[16:03] <smartboyhw> yep
[16:03] <balloons> I caught a bit of the flavors discussion, and I'll have some words on that
[16:03] <smartboyhw> balloons YAY
[16:03] <SergioMeneses> balloons, perfect!
[16:04] <balloons> I'm with you however -- digesting and responding ;-)
[16:04]  * smartboyhw waits for blog post
[16:15] <njin> balloons, I write the first testcase (upgrade) and downloaded the bzr
[16:16] <balloons> njin, excellent
[16:16] <balloons> we were talking about wanting to use it next week for cadence week 8
[16:16] <smartboyhw> yeah
[16:16] <njin> balloons, now the next step is to insert my file into image and push to the bzr ?
[16:17] <smartboyhw> njin yes
[16:17] <smartboyhw> Make sure you run bzr add
[16:17] <njin> ok, the file number is assigned by the revisioner '
[16:18] <njin> ?
[16:18] <balloons> njin, yes.. since it's new, you can upload without a number
[16:18] <balloons> ohh
[16:18] <balloons> https://wiki.ubuntu.com/QATeam/ContributingTestcases/ManualStyleGuide
[16:19] <balloons> that will be helpful ^^
[16:19] <smartboyhw> njin: Normally it would be the testcase no. in the QA Tracker
[16:19] <njin> is a new testcase
[16:19] <balloons> njin, yea check out that page
[16:19] <balloons> it will explain things..
[16:20] <njin> ok, looking
[16:51] <balloons> njin, looking ;-)
[16:51] <njin> thanks
[16:53] <balloons> hmm.. the diff is blank
[16:53] <balloons> did you add the new file to your branch?
[16:53] <balloons> you have to use bzr add FILENAME
[16:53] <njin> ok, redo things
[16:53] <balloons> njin, https://code.launchpad.net/~fabiomarconi/ubuntu-manual-tests/upgrade_from_image
[16:53] <SergioMeneses> maybe njin could use: bzr diff
[16:54] <balloons> yea, I don't see a commit from you in there yet
[16:54] <balloons> overall.. you need to do this
[16:54] <balloons> 1) create new file
[16:54] <balloons> 2) use bzr add FILENAME
[16:54] <balloons> 3) bzr commit
[16:54] <balloons> 4) bzr push
[16:54] <balloons> make sense? you make the file, add it to the branch.. commit the branch, and then finally push it to launchpad
[16:55]  * balloons is excited
[16:55] <SergioMeneses> balloons, about?
[16:55] <balloons> SergioMeneses, multi-tasking certainly, but yes ;0
[16:55] <SergioMeneses> :O :)
[16:55] <smartboyhw> lol
[17:06] <balloons> njin, looks like it worked :-)
[17:06] <balloons> I see the test
[17:07] <njin> ok, thanks
[17:07] <SergioMeneses> congrats njin :)
[17:07] <balloons> So basically what happens now is it will be reviewed, then merged into the trunk and synced to the tracker
[17:08] <balloons> and yes congrats... :-) You are free to make testcases now! Go forth and write!
[17:08] <njin> ok, but for the other part we need to wait for the fix (upgrade inserting the media in the running system)
[17:10] <balloons> njin, ohh right! good point. can we get another bug report on our tracker for that? and link to the launchpad bug for the fix?
[17:10] <njin> balloons, https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1152148
[17:10] <balloons> njin perfect.. can you open the bug on our tracker so we can track our need for the testcase for it?
[17:11] <njin> sure
[17:11] <balloons> thanks!
[19:38] <Noskcaj> balloons, someone killed the lubuntu installer theme, and phillw is AFK. can you try and get someone to confirm it, i haven't  had time to make a bug
[19:38] <balloons> Noskcaj, on the daily eh?
[19:39] <balloons> Noskcaj, morning :-)
[19:39] <Noskcaj> balloons, morning, yeah
[19:39] <Noskcaj> or about a week
[19:39] <balloons> I'll be back in a bit.. you can always ping
[19:40] <Noskcaj> ok
[19:41] <balloons> on #lubuntu
[19:41] <balloons> or the mailing list if no one is about
[19:59] <Noskcaj> bug 1152306
[20:03] <xnox> Noskcaj: it's absolutely fine.
[20:04] <xnox> Noskcaj: there is no background, but that is pending on ubiquity upload.
[20:04] <xnox> Noskcaj: to be done now.
[20:04] <balloons> xnox, Noskcaj ahh.. yea, so it's a black background.. Noskcaj you'll notice little things like that throughout the cycles.. anything that has to do with art will get updated at some point during the cycle
[20:05] <balloons> for instance, the fact it still says 12.10 everywhere (or did.. it's getting close to time that should be fixed)
[20:05] <Noskcaj> not the black background, the window theme itself, note the blue-ness
[20:06] <Noskcaj> and the minimise button
[20:06] <xnox> Noskcaj: a screenshot of what you'd expect it to be would be nice. E.g. on a working lubuntu install package ubiquity, launch it and take a comparison screenshot.
[20:06] <xnox> cause I don't know / use lubuntu so no idea what it is meant to look like =) overall it looks fine to me at first glance.
[20:06] <Noskcaj> i'm afraid i don't have one, maybe google images has it
[20:07] <Noskcaj> http://i52.tinypic.com/v7s1e9.jpg
[20:28] <Noskcaj> xnox, screencap added
[20:28] <xnox> Noskcaj: thanks.
[20:30] <balloons> thx :-)


[09:24] <jared> Anyone know a good bandwidth monitoring program? I would prefer logged rather than live.
[09:25] <jared> About 2 months ago the home internet use has gone from 20gb a month to near the 50 limit without any gradual creep, just a sudden jump.


[06:28] -queuebot:#ubuntu-release- New: accepted extrepo [amd64] (focal-proposed) [0.2]
[06:28] -queuebot:#ubuntu-release- New: accepted notepadqq [amd64] (focal-proposed) [2.0.0~beta1-1]
[06:28] -queuebot:#ubuntu-release- New: accepted notepadqq [armhf] (focal-proposed) [2.0.0~beta1-1]
[06:28] -queuebot:#ubuntu-release- New: accepted python-portend [amd64] (focal-proposed) [2.5-1]
[06:28] -queuebot:#ubuntu-release- New: accepted python-pyani [arm64] (focal-proposed) [0.2.9-1]
[06:28] -queuebot:#ubuntu-release- New: accepted python-pyani [i386] (focal-proposed) [0.2.9-1]
[06:28] -queuebot:#ubuntu-release- New: accepted python-pyani [s390x] (focal-proposed) [0.2.9-1]
[06:28] -queuebot:#ubuntu-release- New: accepted ruby-murmurhash3 [arm64] (focal-proposed) [0.1.6-1]
[06:28] -queuebot:#ubuntu-release- New: accepted ruby-murmurhash3 [i386] (focal-proposed) [0.1.6-1]
[06:28] -queuebot:#ubuntu-release- New: accepted ruby-murmurhash3 [s390x] (focal-proposed) [0.1.6-1]
[06:28] -queuebot:#ubuntu-release- New: accepted kirigami-gallery [sync] (focal-proposed) [19.04.3-1]
[06:28] -queuebot:#ubuntu-release- New: accepted notepadqq [i386] (focal-proposed) [2.0.0~beta1-1]
[06:28] -queuebot:#ubuntu-release- New: accepted python-pyani [armhf] (focal-proposed) [0.2.9-1]
[06:28] -queuebot:#ubuntu-release- New: accepted ruby-murmurhash3 [amd64] (focal-proposed) [0.1.6-1]
[06:28] -queuebot:#ubuntu-release- New: accepted ruby-murmurhash3 [ppc64el] (focal-proposed) [0.1.6-1]
[06:28] -queuebot:#ubuntu-release- New: accepted vtkplotter [amd64] (focal-proposed) [2019.1.2-2]
[06:28] -queuebot:#ubuntu-release- New: accepted notepadqq [arm64] (focal-proposed) [2.0.0~beta1-1]
[06:28] -queuebot:#ubuntu-release- New: accepted python-pyani [ppc64el] (focal-proposed) [0.2.9-1]
[06:28] -queuebot:#ubuntu-release- New: accepted vitrage-dashboard [amd64] (focal-proposed) [2.0.0-1]
[06:28] -queuebot:#ubuntu-release- New: accepted python-pyani [amd64] (focal-proposed) [0.2.9-1]
[06:28] -queuebot:#ubuntu-release- New: accepted ruby-murmurhash3 [armhf] (focal-proposed) [0.1.6-1]
[07:59] -queuebot:#ubuntu-release- Unapproved: haproxy (bionic-proposed/main) [1.8.8-1ubuntu0.7 => 1.8.8-1ubuntu0.8] (ubuntu-server)
[09:39] <cpaelzer> anyone around to accept https://code.launchpad.net/~paelzer/britney/hints-ubuntu-focal-spice/+merge/375632 to get this out of proposed migratioN?
[09:43] <Laney> cpaelzer: done, and agreed re: dropping crappy tests
[09:43] <cpaelzer> thanks
[10:12] <mwhudson> geoalchemy2 has regressed in release: https://autopkgtest.ubuntu.com/packages/geoalchemy2/focal/amd64
[11:11] -queuebot:#ubuntu-release- New binary: pycifrw [ppc64el] (focal-proposed/universe) [4.4-2] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: pycifrw [amd64] (focal-proposed/universe) [4.4-2] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: pycifrw [s390x] (focal-proposed/universe) [4.4-2] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: pycifrw [i386] (focal-proposed/universe) [4.4-2] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: pycifrw [arm64] (focal-proposed/universe) [4.4-2] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: thawab [amd64] (focal-proposed/none) [4.1-2] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: pycifrw [armhf] (focal-proposed/universe) [4.4-2] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: mmtf-java [amd64] (focal-proposed/universe) [1.0.9-4] (no packageset)
[11:29] -queuebot:#ubuntu-release- New: accepted mmtf-java [amd64] (focal-proposed) [1.0.9-4]
[11:29] -queuebot:#ubuntu-release- New: accepted pycifrw [arm64] (focal-proposed) [4.4-2]
[11:29] -queuebot:#ubuntu-release- New: accepted pycifrw [i386] (focal-proposed) [4.4-2]
[11:29] -queuebot:#ubuntu-release- New: accepted pycifrw [s390x] (focal-proposed) [4.4-2]
[11:29] -queuebot:#ubuntu-release- New: accepted pycifrw [amd64] (focal-proposed) [4.4-2]
[11:29] -queuebot:#ubuntu-release- New: accepted pycifrw [ppc64el] (focal-proposed) [4.4-2]
[11:29] -queuebot:#ubuntu-release- New: accepted pycifrw [armhf] (focal-proposed) [4.4-2]
[11:29] -queuebot:#ubuntu-release- New: accepted thawab [amd64] (focal-proposed) [4.1-2]
[16:09] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (bionic-proposed/restricted) [340.107-0ubuntu<IP_ADDRESS> => 340.107-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[17:58] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [amd64] (bionic-proposed) [1:9-2~ubuntu18.04.1]
[17:58] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [armhf] (bionic-proposed) [1:9-2~ubuntu18.04.1]
[17:58] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [ppc64el] (bionic-proposed) [1:9-2~ubuntu18.04.1]
[17:59] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [arm64] (bionic-proposed) [1:9-2~ubuntu18.04.1]
[17:59] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [s390x] (bionic-proposed) [1:9-2~ubuntu18.04.1]
[17:59] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [i386] (bionic-proposed) [1:9-2~ubuntu18.04.1]
[18:04] -queuebot:#ubuntu-release- Unapproved: libclc (bionic-proposed/universe) [0.2.0+git20190306-1~ubuntu18.04.1 => 0.2.0+git20190827-1~ubuntu18.04.1] (no packageset)
[18:17] -queuebot:#ubuntu-release- Unapproved: accepted libclc [source] (bionic-proposed) [0.2.0+git20190827-1~ubuntu18.04.1]
[18:30] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [19.6~ubuntu14.04.3 => 19.6~ubuntu14.04.4] (no packageset)
[18:32] -queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.8-0ubuntu0~18.04.3 => 19.2.1-1ubuntu1~18.04.1] (core, xorg)
[18:37] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (bionic-proposed) [340.107-0ubuntu<IP_ADDRESS>]
[18:52] -queuebot:#ubuntu-release- Unapproved: ddcci-driver-linux (bionic-proposed/universe) [0.3.1-2 => 0.3.1-2ubuntu0.1] (no packageset)
[19:32] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [19.2.1-1ubuntu1~18.04.1]
[19:35]  * infinity raises an eyebrow at texlive-base, tex-common, emacs, and imagemagick (among others) all trying to move to universe...
[19:35] <infinity> Did someone just unseed some stuff they didn't care about?
[19:38] <infinity> Not that I'm against emacs being demoted (viva la vim!), but I might be biased.
[19:41] <infinity> Ahh, there it is.  The latest commit from laney to platform.focal
[19:41] <infinity> vorlon: Looks like the desktop team is washing their hands of emacs (and, thus, its dep chain).  Do we care enough to pick it up elsewhere, or good riddance?
[19:46] <xnox> infinity:  given that security team member publishes emacs as a classic snap, i wonder if i should just switch to using that one.
[19:47] <xnox> we used to care to build emacs bindings, but thanks to archive reorg we no longer need emacs in main to have a useful emacs-flavour-lisp compiler available as a build-dep.
[19:47] <infinity> xnox: I mean, it's not like we've ever had an emacs security update, so I'm not sure demoting to universe changes anything anyway.
[19:48] <infinity> The side-effect of dropping texlive-base out of supported is perhaps a bit weirder, but I think that was the desktop team's intent. :)
[19:49] <infinity> Laney: You could drop TeX entirely from main if evince didn't depend on it.  If maybe that bit could be made an optional plugin or something.
[19:49] <infinity> Laney: Not that I'm suggesting you should do that, but yeah, since your emacs change, literally the only thing keeping it in appears to be evince.
[19:49] <xnox> imho texlive-base in archive is also simply a -doc packages build-dep. Anyone serious about using texlive installs TeXLive distribution; or any other one. Back in the day, debian/ubuntu-distro packaged texlive distribution was the only conherent thing, but these days upstream TeXLive is fabilous with tested coherent sets of packages.
[19:50] <infinity> xnox: I hate that argument every time it's made for Package X.
[19:50] <xnox> especially to get all the tikz / luatex / etc
[19:50] <xnox> we really don't package enough of texlive =)))))
[19:50] <infinity> xnox: If "people serious about X always use upstream's build of X", then we've failed to do it right.
[19:51] <xnox> and mix and matching tex used to suck a lot, maybe that got better.
[19:51] <infinity> For some things, the answer is "stop doing it entirely" (like, PHP PEAR crap, or literally any webapp, or, or) and sometimes, it's "do it better".
[19:51] <xnox> But in practice, people do deploy bundled things using pep, gems, bundler, go vendor, juju charms, etc.
[19:52] <mdeslaur> amurray: hey emacs boy, ^
[19:52] <infinity> But yeah, if we don't want to invest Ubuntu time in it, and the Debian stuff is mediocre, that's a solid reason to also avoid supporting it.
[19:52] <xnox> we absolutely should/must support the bits of texlive that doxygen et.al.friends need though.
[19:52] <xnox> which is a small subset of the whole texlive.
[19:53] <infinity> xnox: we don't support doxygen. :P
[19:53] <xnox> because being able to compile upstream docs into pdf is a must
[19:53] <infinity> xnox: Maybe that should be fixed, which would yank some TeX back in, but right now, it's in universe.
[19:53] <xnox> we use it as a build-dep, and put the results into main, i.e. -doc packages
[19:53] <infinity> xnox: Yes, I know.   I remember limiting myself to whatever was in Ubuntu, or vendoring packages, because of it.
[19:57] <xnox> *that
[19:57] <infinity> xnox: Okay... and?
[19:57] <xnox> infinity:  re:off-the-rails i am jetlagged as timezones go
[19:57] <infinity> xnox: No one's removing it from the archive, just from main.
[19:58] <xnox> and => i wouldn't want to harakiri it like we are slicing i386. that.
[19:58] <infinity> Okay, no one's talking about tearing it out of the archive. :P
[19:58] <infinity> I was asking if we cared to keep it in main.
[19:58] <infinity> It started as an emacs question.  And, looking at history, we don't actually provide security support for emacs anyway.
[19:59] <infinity> Either because it has no bugs (hah), or text editor security bugs aren't considered worth anyone's time.
[19:59] <infinity> So, main vs universe for emacs makes no practical difference, AFAICT.
[20:00] <xnox> infinity:  so /usr/lib/x86_64-linux-gnu/evince/4/backends/libpdfdocument.so is what depends on synctex stuff, which let's one synchronize .tex sources with pdf to click and jump to tex source. Pretty much a must when doing tex stuff. It's really nice that it is built in. No idea, if we can make libpdfdocument gracefully dlopen synctex.
[20:01] <infinity> texlive-base has had a security update in trusty/xenial, but while it was clearly a critical CVE in its context, it's less critical in the context of "who actually would trip over this", so...
[20:01] <xnox> or like to have alternative build, which is installed / pulled in by texpackages. and if evince is there, it's magically started to be used/available.
[20:02] <infinity> xnox: Yeah, I'm not suggesting anyone needs to make a plugin solution that works to remove texlive-bin.  Just that if the goal was "get rid of TeX so the desktop team can stop maintaining it", they're one package away from winning. :P
[20:02] <sbeattie> infinity: we've had and fixed a few issues in emacs a while ago, but nothing recent.
[20:02] <infinity> sbeattie: A long while ago, then, since I'm looking at >= precise.
[20:02] <sbeattie> I assume it's just not getting much attention from vulnerability searchers.
[20:03] <infinity> Oh, no I'm not.
[20:03] <infinity> Cause in trusty and xenial, it was emacs24.
[20:03] <infinity> And it did have updates.
[20:03] <sbeattie> yep
[20:03] <infinity> Okay, fair enough.
[20:03] <infinity> So there's some loss of support there, then.
[20:03] <infinity> And maybe we should still explicitly support it in some !desktop seed, but I'll let others argue about that.
[20:04] <infinity> While I'm a fan of Ubuntu's general policy of "pick one default tool to support and leave the rest in universe", I don't know if 15 years in is when we should be picking a winner in the text editor war.
[20:04] <connor_k> the internet would explode
[20:05]  * infinity grabs some quick lunch.
[20:50] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.17]
[23:14] -queuebot:#ubuntu-release- New binary: plyvel [i386] (focal-proposed/none) [1.1.0-2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: plyvel [ppc64el] (focal-proposed/none) [1.1.0-2] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: plyvel [amd64] (focal-proposed/none) [1.1.0-2] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: plyvel [s390x] (focal-proposed/none) [1.1.0-2] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: plyvel [arm64] (focal-proposed/none) [1.1.0-2] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: plyvel [armhf] (focal-proposed/none) [1.1.0-2] (no packageset)


[13:04] <danialbehzadi> Is there a problem with launchpad?
[13:04] <danialbehzadi> my builds got fail with weird logs:
[13:04] <danialbehzadi> https://launchpadlibrarian.net/377127491/buildlog.txt.gz
[13:08] <danialbehzadi> And that happen only for artful and bionic. Cosmic is fine: https://code.launchpad.net/~dani.behzi/+recipe/traktor
[13:09] <popey> danialbehzadi: probably want to ask in #ubuntu-devel maybe
[13:09] <popey> not sure where launchpad people hang out on freenode
[13:10] <danialbehzadi> popey: OK. I thought devel channel is for Cosmic releases and since it was fine with cosmic, I tried to ask here