[00:00] <Laney> oojah: Cool. I have a couple of comments but I'll give you a conditional advocation
[00:00] <oojah> Laney: Ok, thanks.
[00:01] <oojah> What's the condition?
[00:01]  * Laney is writing it on REVU now
[00:01] <oojah> Duh, yeah
[00:01] <rmunn> lfaraone, thanks for the advice on Debian package submission about 15 minutes ago. (Was AFK for a bit). Saved an IRC transcript and I'll read it over later -- only mildly confused at this point, which probably goes to show that I don't have my head wrapped around the process yet. :-)
[00:01] <lfaraone> Short descriptions  should almost always start with a lowercase letter, right?
[00:03] <lfaraone> rmunn: no problem. for "normal" non-python packages (or those where you just feel like "being a rebel"), you can upload to mentors.debian.net (like REVU), and search for a sponsor, but with DPMT you're spared the sponsor search and get the benefits from group-maintenance. :)
[00:03] <BlackZ> good night guys ;)
[00:05] <Laney> oojah: go go go
[00:05] <Laney> you can ping me to re-advocate after you fix it if you want
[00:06] <Laney> but it's not really necessary
[00:07] <oojah> Laney: Thanks very much.
[00:07] <oojah> Very good point about the copyright which ought to have been obvious.
[00:08] <Laney> That's fresh in my mind because I did something with some PD work recently
[00:09] <oojah> I'll have to deal with them tomorrow now.
[00:09] <PATX> i made a needs packaging bug a couple months ago but nothing has really been done... how could i get someone to look at it? https://bugs.launchpad.net/ubuntu/+bug/416634
[00:10] <Laney> !revu
[00:10] <Laney> PATX: use revu if you have a package to submit
[00:10] <lfaraone> PATX: you should submit it to REVU :)
[00:10] <PATX> Laney, thanks :)
[00:10] <PATX> thanks everybody :)
[00:10] <oojah> Laney: Come out some time, I'll buy you a beer.
[00:10] <Laney> oojah: I will and maybe even can now that nlug seems to have moved to Wednesdays
[00:11] <lfaraone> hopefully the next US UDS will be on the East Coast <_<;
[00:11] <Laney> I think I'm doing something this week, but maybe that's lies because I don't actually remember what it is
[00:11] <Laney> oh, going to Fun in the Afternoon in London
[00:12] <james_w> lfaraone: if xdgapp is going to be pulled in to groundcontrol and the package is already in Ubuntu then we should remove xdgapp from Ubuntu for this release IMO
[00:12] <oojah> I rarely make it to nlug, but will be meeting former nlug peeps for drinks at some point in the next few weeks.
[00:12] <Laney> oojah: let me know if it's not a monday/thursday and I'll see what I can do
[00:12] <oojah> Will mention it in #nlug.
[00:12] <PATX> How do I upload to REVU?
[00:12] <oojah> Night!
[00:12] <lfaraone> james_w: well, we're still on appeal on that one :)
[00:12] <Laney> cool
[00:13] <Laney> see ya
[00:13] <lfaraone> PATX: see https://wiki.ubuntu.com/MOTU/Packages/REVU
[00:13] <DmitryKurochkin> I am repeating myself, but if someone has time to review a package, please take a look at http://revu.ubuntuwire.com/p/polygraph. The is one advocation already.
[00:15] <bdrung_> oojah: the link in debian/watch should be a comment, too
[00:20] <Laney> oh, rats
[00:20] <Laney> I noticed another thing >:(
[00:20] <bdrung_> Laney: ?
[00:21] <Laney> get-orig-source should always download the same thing
[00:22] <bdrung_> it will get more complex
[00:22] <Laney> so?
[00:23] <Laney> its purpose is to reconstruct the upstream tarball
[00:23] <Laney> oh shit
[00:23] <Laney> !language
[00:24] <Laney> that's actually a lie, and me misremebering policy
[00:24]  * Laney thinks that policy is wrong here
[00:24] <bdrung_> Laney: it has to grep the upstream version from debian/changelog and get the right git revision to checkout
[00:25] <bdrung_> (and not the other way around)
[00:25] <Laney> actually it has to get the most recent version
[00:25] <Laney> but I would rather it got the version that we want to upload
[00:26] <Laney> dpkg-parsechangelog can make this easy enough
[00:30] <PATX> Ok, so how long will it take for two MOTUs to review http://revu.ubuntuwire.com/p/fastpatx ?
[00:31] <Laney> a long time :)
[00:31] <Laney> you might try PAPT in Debian
[00:32] <PATX> PAPT?
[00:32] <bdrung_> PATX: fix all lintian reports and then ask again
[00:32] <PATX> bdrung_ ok...
[00:35] <lfaraone> PATX: example, apparently you're building a debian-native package. Did you forget to include the orig.tar.gz file above where your package directory is?
[00:36] <lfaraone> Laney: oh, that's what policy says? screw policy, then.
[00:36] <lfaraone> Laney: that's really odd.
[00:36] <Laney> yes, it sucks
[00:37] <lfaraone> Laney: here's the get-orig-source rule I used for a git-using package I work on: http://bazaar.launchpad.net/~lfaraone/gtksheet/debian/annotate/head%3A/debian/rules#L19 , that might be useful to borrow from.
[00:38] <Laney> lfaraone: tell it to oojah
[00:38]  * Laney is a mere reviewer here
[00:38] <lfaraone> oojah: here's the get-orig-source rule I used for a git-using package I work on: http://bazaar.launchpad.net/~lfaraone/gtksheet/debian/annotate/head%3A/debian/rules#L19 , that might be useful to borrow from.
[01:18] <PATX> ok one error is that my email is not @ubuntu.com how can i fix this?
[01:20] <persia> PATX: Run update-maintainer in the package directory
[01:20] <PATX> ok thanks then i can use my email?
[01:20] <persia> How do you mean?
[01:21] <StevenK> I think he wants to set the maintainer address to his own e-mail address
[01:21] <PATX> well i do not have a<EMAIL_ADDRESS>so when i upload the pkg to REVU i need to use my gmail correct?
[01:21] <PATX> StevenK, could i do anything else?
[01:22] <PATX> but yea thats what i want
[01:23] <persia> PATX: If you're submitting something to be included in Ubuntu, you want to set the maintainer to be an Ubuntu team (all the developers is the default).  The common practice is to set one's own name and email as XSBC-Original-Maintainer.  If you already have your own name and email as the Maintainer, update-maintainer will do this automatically.
[01:23] <PATX> ok
[01:23]  * persia wonders if this remains appropriate default behaviour given the proliferation of third-party repositories for which nobody in Ubuntu wishes to claim any responsibility
[01:24] <PATX> do i run that before or after buildng?
[01:24] <persia> At any point, but you'll want to have run it before you prepare the source package for upload.
[01:25] <PATX> ok
[01:34] <PATX> Ok now how would I go about fixing "This package has no debian/watch file or get-orig-source rule."?
[01:46] <persia> PATX: man uscan to read about watch files
[01:46] <PATX> ok ty
[01:51] <PATX> persia, so i have to make a debian/watch???
[01:52] <persia> That's the best practice, yes.
[01:52] <PATX> would my pkg have any chance of getting in w/ out one?
[01:54] <persia> PATX: How would anyone know when the package needs to be updated without one?
[01:54] <PATX> idk
[01:54] <persia> But that aside, since FeatureFreeze is in a couple days, your application has a decidedly low chance of making it anyway.
[01:55] <persia> But yeah, the watch file is an important component of our ability to make sure the archive is in reasonable shape.
[01:55] <PATX> ok
[01:56] <PATX> so should i just wait to do this untill the next version of ubuntu?
[01:58] <persia> Actually, now isn't a bad time to get a package in shape.
[01:58] <persia> But don't be surprised if it doesn't make the lucid deadline.
[01:58] <persia> My recommendation would be to get the package in the best shape you can, and submit it to Debian.
[01:58] <persia> That way it can be synced when archive opens for the next release.
[01:59] <persia> if it doesn't get into Debian in that time, you can go back to chasing REVU.
[01:59] <PATX> ok
[03:24] <Gaming4JC> I wasn't quite sure where to ask this, but the BZFlag client is out dated in the main repos - since they came out with an entirely new client today. http://sourceforge.net/projects/bzflag/
[03:27] <persia> Today?  Ugh.  That doesn't leave much time.
[03:28] <persia> Please file a bug against bzflag requesting an upgrade.
[03:28] <Gaming4JC> using launchpad?
[03:28]  * Gaming4JC goes there...
[03:28] <persia> ubuntu-bug bzflag is probably the easiest way to file it.
[03:32] <Gaming4JC> ok thanks, and what about another substantially outdated one... Blender?
[03:32] <Gaming4JC> file a bug report for that too? 2.49b has been out for almost a year
[03:32] <Gaming4JC> lol
[03:33] <persia> Blender is kinda special.
[03:33] <wgrant> 2.49.2 is in Lucid.
[03:33] <wgrant> And yes, Blender is a very special thing.
[03:34] <Gaming4JC> really? o.O
[03:34] <wgrant> Ah, and 2.49.2 is actually 2.49b
[03:55] <Gaming4JC> persia: This correct? :) https://bugs.launchpad.net/ubuntu/+source/bzflag/+bug/522448
[03:56] <nigelb> I've been working on fixing a small bug, but I run into issues because the quilt patch is applying changes on a file that gets deleted at build time.  So, how do I go about fixing it?
[03:57] <persia> Gaming4JC: Except I don't know why you've made it private.
[03:57] <persia> nigelb: Why are you patching a file that gets deleted at build time?
[03:57] <Gaming4JC> persia: hmm, I'm unsure as well considering I never checked that option anywhere lol o.O
[03:58] <persia> Gaming4JC: If you make it less private, I'll tell you if it works.
[03:58] <nigelb> persia: I'm still unsure where its being deleted at build time or renamed
[03:58] <nigelb> s/where/whether
[03:58] <persia> nigelb: The build log should tell you.
[03:58] <nigelb> where do I see the build log?
[03:59] <nigelb> ah, the .build file
[03:59] <persia> How did you build it?
[04:00] <nigelb> debuild -S -sa
[04:00] <nigelb> yes, it is getting deleted "rm -f rules/evdev rules/evdev.xml.in"
[04:00] <Gaming4JC> persia: made it public. :)
[04:00] <nigelb> so that means, I can ignore the mistake in that file since its going to be deleted anyway?
[04:01] <persia> nigelb: Maybe: it depends on whether it gets used before it is deleted.
[04:01] <nigelb> Is it possible to figure that out from the logs?
[04:02] <persia> Usually.  Look for previous uses of the filename in the log.
[04:03] <nigelb> only the rm -f statement
[04:03] <persia> Then it's probably not used.
[04:03] <nigelb> so, I can skip patching that file and its okay?
[04:03] <persia> Gaming4JC: Did bzflag do their usual thing and not allow older clients?
[04:03] <persia> nigelb: Test and see :)
[04:03] <nigelb> thank you.  Checking now :)
[04:03] <Gaming4JC> persia: sort of, they still allow the old client but keep telling me to update all the time
[04:04] <persia> Gaming4JC: Hrm.  That's better than it used to be, but still a clear hint.  Thanks.
[04:04] <Gaming4JC> np :)
[04:04] <Gaming4JC> well, 'tis late here
[04:04] <Gaming4JC> ttyl and thank man :D
[04:04] <Gaming4JC> thanks*
[04:26] <nigelb> how do I know pbuilder successfully built a package? lack of errors?
[04:36] <suji11> how to create package for hunspell-ta ? i'm having the dic file and aff file.
[04:49] <suji11> how to i review the packages in revu.ubuntuwire.com
[04:54] <nigelb> I'm looking for a main sponser to review a patch I have submitted :)
[04:54] <nigelb> anyone around?
[04:55] <nigelb> persia: ^^
[04:56] <nigelb> bug 398873
[05:48] <micahg> any ubuntu-sru members around to see if something is SRU worthy?
[05:58] <micahg> nigelb: main sponsors are in #ubuntu-devel
[06:02] <nigelb> oh, thanks micahg
[06:58] <eagles0513875> hey guys i have read through the packaging documentation. how does one determine out of the various packaging methods available which one is the best for that particular package or situation?
[07:15] <toabctl> i try to fill a syncrequest with: requestsync -d unstable -n --lp -s python-pisa lucid
[07:15] <toabctl> but the error is: E: The package 'python-pisa' does not exist in the Debian primary archive in 'sid'
[07:16] <toabctl> but the package is available: see http://packages.debian.org/sid/python-pisa
[07:22] <randomaction> toabctl: this package is very new
[07:23] <toabctl> randomaction, yes. that's a problem?
[07:23] <randomaction> try again in several hours
[07:23] <toabctl> ok
[07:23] <toabctl> thx
[07:23] <randomaction> yes, PTS has no information on it yet: http://packages.qa.debian.org/p/pisa.html
[07:26] <eagles0513875> randomaction: im just wondering. i read through all the packaging guide and im a little lost. how does one determine which method is correct to use or does it depend on what the type of package is
[07:27] <randomaction> eagles0513875: What's your problem?
[07:27] <eagles0513875> randomaction: not a problem im just trying to understand the purpose of having so many different packaging methods and how to choose the right one. im hoping to eventually become an motu but i need to get my packaging skills up to snuff first.
[07:35] <dholbach> good morning
[07:37] <eagles0513875> good morning dholbach
[07:38] <dholbach> hi eagles0513875
[07:38] <eagles0513875> dholbach: are motus responsible for all repos? or just in charge of the packages
[07:40] <dholbach> eagles0513875: as a MOTU you can upload packages to universe and multiverse
[07:41] <eagles0513875> im not motu yet im still trying to figure out packaging. i read through the complete packaging guide yet im confused as to how to determine which out of all the options available for packaging is ideal to use, or is it dependent on the type of package that needs to be created?
[07:42] <dholbach> there's lots of different ways to get a package done
[07:42] <eagles0513875> so it is dependent on what i get used to
[07:42] <dholbach> I learned the most by working on existing packages
[07:43] <dholbach> so you just modify small bits here and there in order to fix a bug and you get exposed to whatever the maintainer thought they'd use for packaging
[07:43] <dholbach> that way you learn multiple approaches
[07:43] <eagles0513875> ok kool will give that a try :)
[07:44] <eagles0513875> question about mentoring. it is where someone takes me for ex under their wing and shows me how to fix the bugs etc?
[07:44] <dholbach> AFAIK the mentoring programme is having difficulties at the moment
[07:45] <dholbach> so it's probably better to start off on your own and just ask questions in here
[07:45] <dholbach> there's always somebody around to help out
[07:51] <iulian> G'morning dholbach.
[07:51] <dholbach> oi iulian! how are you doing?
[07:54] <iulian> dholbach: I'm doing fine.  How about you?
[07:54]  * iulian is doing his physics homework now.
[07:55]  * eagles0513875 is doing programming hw
[07:55] <dholbach> iulian: good - thanks :)
[07:55] <eagles0513875> dholbach: last question. whose in charge over all of maintaining the repositories? cuz im trying to upgrade from karmic to lucid and im getting a 403 on one of the repos
[07:58] <dholbach> eagles0513875: https://launchpad.net/ubuntu/+archivemirrors
[07:58] <dholbach> some mirrors might be a bit out of sync
[07:58] <eagles0513875> this one hasnt been working since yesterday though
[08:03] <slytherin> Does anyone know what does 'Apply to be an official mirror of this distribution' mean when registering new mirror?
[08:11] <eagles0513875> slytherin: you got me curious as well about that
[08:12] <slytherin> eagles0513875: If I understand correctly the official mirror (whichever it is) will be used by installer when doing a fresh install.
[08:15] <eagles0513875> slytherin: i dont quite understand
[08:16] <slytherin> eagles0513875: When I install Ubuntu from scratch the installer will have a list of official mirror for each country. So if the country I selected ininstaller has a official mirror assigned that mirror will be set in /etc/apt/sources.list.
[08:23] <eagles0513875> slytherin: i know that but the one i have i hate using it cuz its on such a slow connection. and there is only one for my country. im wondering if i could setup a virtual machine with another mirror for my country
[08:24] <slytherin> eagles0513875: Or you could buy some hosting space through community funding and manager a mirror.
[08:24] <slytherin> s/manager/manage
[08:24] <eagles0513875> i have a monster desktop that i can run a vm on. thats not a problem for me
[08:26] <slytherin> eagles0513875: Do you own a domain and static IP?
[08:26] <eagles0513875> i do own a domain but its pointed at another server atm :(
[08:31] <slytherin> eagles0513875: you can use services such a sdyndns
[08:31] <slytherin> http://www.dyndns.com/
[08:31] <eagles0513875> slytherin: i already do
[08:32] <slytherin> then setting up the mirror should not be a big trouble.
[08:32] <eagles0513875> slytherin: do you have any documentation or anything for that
[08:32] <slytherin> I believe Ubuntu wiki does have some documentation.
[08:33] <slytherin> eagles0513875: https://wiki.ubuntu.com/Archive/Mirroring
[08:33] <eagles0513875> thanks slytherin
[09:09] <oojah> Laney: I've uploaded a new sqlite3-pcre if you wanted to check the get-orig-source.
[09:29] <Laney> advocated
[09:32] <oojah> Ta
[10:45] <oojah> I'm looking for a second advocate for http://revu.ubuntuwire.com/p/sqlite3-pcre Can anybody help?
[11:21]  * Laney adds a ticker to the agda-stdlib build
[11:21] <Laney> Agda + armel are not friends
[11:22] <persia> Laney: How does the ticker work?  I think schroot suffers from the same issue (although it may be that it's trying to build stuff that shouldn't be built for arch:any)
[11:24] <Laney> persia: it just generates some output so the build isn't timed out
[11:25] <persia> Laney: Does one do this with a parallel process, or just extra noisiness in the part that hits the timeout?
[11:25] <Laney> a parallel process (it's just a simple shell script)
[11:25] <Laney> watches for the build's PID and the creation of the build-stamp file, typically
[11:26] <Laney> http://git.debian.org/?p=pkg-haskell/agda.git;a=blob;f=debian/watcher.sh;h=0de582d7162cd262e89a43dbd19c154d460ca294;hb=HEAD
[11:26] <Laney> like that
[11:26] <persia> Laney: And how does one call it?
[11:27] <Laney> sh debian/watcher.sh "$$PPID" "$(CURDIR)" "$(CURDIR)/build-stamp" 'ghc' &
[11:28] <Laney> the locking part was added by me because I couldn't figure out how to get cdbs not to call it multiple times
[11:29] <persia> So PPID is the PID of the make executing debian/rules?
[11:29] <Laney> yes
[11:30] <persia> Nifty.  I'll definitely have to give that a shot.
[11:30] <Laney> you could definitely make it more specific to your failure case, but this is general enough to work without much effort
[11:31] <Laney> even if it adds some noise to the build output
[11:33] <persia> Laney: That's why I asked :)  I wanted something that didn't require thought to get stuff to compile.  Actually optimising to make it not need to take so long is step two.
[12:01] <lbrinkma> What's the status about the libmysqlclient problem?
[12:02] <persia> lbrinkma: last I saw there was still discussion about how to fix it in an sane manner.  I thought it only affected building packages.
[12:04] <lbrinkma> persia: yes, it's true. But i want to upload a package to REVU that depends on anjuta and anjuta depends on libaprutil, and that on libmysqlclient. So it won't work
[12:04] <persia> REVU doesn't build anything, so it'll be fine.
[12:05] <lbrinkma> persia: but it's hard to test it when i can't build it
[12:05] <persia> lbrinkma: Indeed, and hard to review for the same reason :)
[12:32] <paissad> i know it's not a question related to the channel, but  i just would like to know if ppa lauchnpad accepts uploads of freewares ( i packaged a software whose source code is not available .... it's already built)
[12:35] <slytherin> paissad: The Launchpad usage policy forbid that.
[12:35] <paissad> slytherin, ok thanks
[12:36] <persia> Does it?
[12:36] <persia> I know Ubuntu accepts some freeware under certain conditions (but we don't like it, and drop it if it's buggy)
[12:44] <slytherin> paissad: persia: I remember reading the usage conditions some time back. Can not find a link to it now. Asking on #launchpad for clarification is best.
[12:45] <persia> Generally :)
[12:49] <slytherin> paissad: Found this - https://help.launchpad.net/PPATermsofUse
[12:49] <paissad> ok
[12:52] <om26er> if it want to update a package in lucid what should I do? open [needs packaging] bug or needs update/or something like that?
[12:54] <slytherin> om26er: Are you going to work on update?
[12:54] <persia> om26er: It's not a "needs packaging" bug.  It's an "upgrade" bug.  Just identify the target version, the rationale, and add the upgrade tag.
[12:54] <om26er> persia, ok, thanks
[12:54] <om26er> slytherin, I will try :)
[12:55] <slytherin> as persia said, it is upgrade bug. But if the package exists in Debian then first check if anyone is working on upgrade.
[12:57] <om26er> slytherin, it just released
[12:57] <om26er> like an hour ago
[12:58] <slytherin> om26er: that does not mean you have to update it in Ubuntu first. :-)
[13:23]  * Laney is going to kick off the haskell transition later, probably
[13:23] <Laney> fun fun fun :)
[13:30] <Laney> later = now
[13:30]  * Laney uploads ghc6
[13:32] <persia> Go, Go, Go!
[13:34] <Laney> http://people.canonical.com/~pitti/scripts/syncpackage is a useful script
[13:35] <persia> Laney: Take care: I've seen requests that people not use that.
[13:36] <persia> Laney: It's usually not *too* hard to get a friendly archive-admin to do a batch together.
[13:36] <Laney> persia: how come?
[13:36] <Laney> I will be requesting a *lot* of syncs in the next days
[13:36] <persia> Because, although it does mostly the right thing, it does it in a way that is messy within Soyuz somehow.
[13:36] <Laney> oh
[13:37] <persia> Just find an archive admin, and tell them the plan, and have them run the syncs.
[13:37] <persia> I believe the current script is similar to the one you referenced, but it's designed to be run inside Soyuz, from what I understand.
[13:38] <Laney> it will just look like a normal upload
[13:38] <Laney> maybe syncs have some special processing
[13:38] <persia> They do.
[13:38]  * persia doesn't know the details, but suspects an archive-admin would be willing to explain.  Might ask in -devel
[13:38] <Laney> james_w: ^^^ ?
[13:40] <james_w> Laney: I'd be happy to bulk-sync things for you
[13:41] <Laney> cool. Is it really not advised to use that script?
[13:41]  * Laney mainly does it to avoid hassling people
[13:41] <ripps> Hey, any broken packages that need some packaging fixed? I looking to help a bit
[13:42] <Laney> subject: ghc6_6.12.1-9_source.changes rejected
[13:42] <Laney> :(
[13:42] <Laney> james_w: could you do that sync? ghc6 from unstable
[13:42] <james_w> Laney: I'd only be repeating what others told me if I said that it wasn't advised. I don't know the details
[13:42] <Laney> it's a big orig
[13:42] <james_w> Laney: I can try
[13:42] <Laney> thanks
[13:52] <directhex> what's the best way to turn a normal bug into a requestsync?
[13:52] <Laney> edit the title and description, i'd have thought
[13:52] <Laney> or invalid it and requestsync again
[13:52] <Rhonda> And add the appropirate team.
[13:52] <directhex> & subscribe archive admin, since i'm motu & it's in loonyverse?
[13:52] <Laney> yes
[13:53] <Laney> + confirmed
[13:53] <sebner> persia: urgh, cjwatson is on holidays this week, we have to find someone else to backport it on the buildmachines :\
[13:54] <persia> sebner: Check with jdong about the base backport: he is the backport master (but first make sure a backport to hardy works locally for you)
[13:54] <sebner> directhex: + wishlist if you are motivated :P
[13:55] <sebner> persia: aye
[13:56] <directhex> if --lp is recommended, as per --help, then why isn't it the default behaviour?
[13:56] <Laney> it requires setting up credentials, I guess
[13:56] <Laney> higher barrier to entry
[13:57] <sebner> Laney: funnily that never worked for me ¬_¬
[13:57] <Laney> ~/.udtrc would be good though
[13:57] <Laney> sebner: what's that?
[13:58] <slytherin> ripps: take a look at FTBFS page. http://qa.ubuntuwire.com/ftbfs
[13:58] <sebner> Laney: setting up credentials
[13:59] <slytherin> sebner: What problem did you get?
[13:59] <geser> directhex: mostly historic reason, as requestsync was using mail at first, then later used python-launchpad-bugs (still before the LP API) nobody wanted to change the default of "mail"
[14:00] <sebner> slytherin: hmm, can't remember but I'll give it another try so we can discuss that. Btw, what benefit do I have from it?
[14:00] <slytherin> sebner: When you use --lp it retrives info from Launchpad and hence will skip a few questions.
[14:00] <geser> sebner: you could use "ubuntu-build" for give-backs :)
[14:01] <slytherin> geser: I believe the command is buildd
[14:01] <sebner> ah, yes that's quite something useful :D
[14:02] <geser> slytherin: no, it got renamed to ubuntu-build in lucid since it conclicted with buildd from the package buildd (and I'm sure about it as I did the rename :)
[14:03] <slytherin> Oh. I haven't moved to lucid yet and do not plan to until it becomes final.
[14:03] <sebner> slytherin: ok, how do I set this stuff up? =)
[14:04] <sebner> geser: what about "package-rebuild" or "ubuntu-rebuild" :P
[14:04] <geser> sebner: "man manage-credentials" and c&p the example from there
[14:04] <slytherin> sebner: man manage-credentials, simplest form - manage-credentials create -c ubuntu-dev-tools
[14:05] <sebner> what level of access is common?
[14:06] <geser> write non-private
[14:06] <geser> you need it for filing sync requests
[14:08] <sebner> persia: argh, I just realized that dpkg itself is now also debsrc3.0 -.-
[14:08] <sebner> slytherin: geser: seems to have worked :D
[14:09] <persia> sebner: Well, in that case, find some recipe that allows you to handle the backport.  Passing someone a working recipe and asking them to execute is surely smoother than "Please do this hard thing" :)
[14:09] <sebner> heh
[14:11] <slytherin> sebner: backporting 3.0 package should not be hard. Try changing the 3.0 in format file to 1.0.
[14:11] <sebner> slytherin: well, it's not that easy with dpkg I suppose :P
[14:11] <slytherin> sebner: How do you know, did you try? :-)
[14:11] <sebner> slytherin: I'm currently looking at it
[14:32]  * Laibsch hopes we don't miss the boat again for http://revu.ubuntuwire.com/p/ffgtk
[14:38] <Laibsch> porthose: maybe you can take another look if it meets your requirements now?
[15:05] <oojah> Could someone please take a look at sqlite3-pcre? I'm looking for a second advocate.
[15:27] <Jeeves_> Hi all
[15:27] <shadeslayer> Jeeves_: hi
[15:27] <Jeeves_> I'm building a private package for sophie (sophos libsavi virusscanner)
[15:27] <Jeeves_> that package depends on libsavi, for which there isn't a package available
[15:28] <Jeeves_> now dh_shlibdeps is byting me.
[15:28] <Jeeves_> Any hints on skipping dh_shlibdeps?
[15:29] <geser> Jeeves_: is libsavi part of sophie?
[15:29] <Jeeves_> geser: No
[15:29] <Jeeves_> It is part of a non-packaged piece of software
[15:29] <Jeeves_> I've tried adding --dpkg-shlibdeps-params=--ignore-missing-info to dh in the rules file
[15:29] <geser> then you need to package it first? else how should your sophie package work with it?
[15:30] <Jeeves_> geser: I install the software before building the package
[15:30] <Jeeves_> I cannot package the other software, which is closed source and dynamically updated
[15:32] <geser> Jeeves_: and your user? the expect that "apt-get install sophie" gives them a working software
[15:32] <Jeeves_> geser: We are the only users.
[15:33] <Jeeves_> It's a private package in a completly controlled environment
[15:36] <geser> the best solution would be to also package libsavi for your use (even if it's closed source, you can skip the compilation part)
[15:37] <ari-tczew> please take a look for clean sync @ bug 522700
[15:37] <Jeeves_> geser: There's no way to skip shlibdebs?
[15:38] <geser> Jeeves_: I don't know of any (which would a hack anyways)
[15:54] <jcastro> hyperair, congratulations!
[15:54] <hyperair> jcastro: thanks. =)
[15:54]  * hyperair just saw jcastro's retweet
[15:54] <jcastro> ok so that means I'll get new banshee in lucid ... ? :p
[16:35] <tsmithe> persia, you around?
[16:36] <mr_steve> Hey MOTUs, if someone could have a look at http://revu.ubuntuwire.com/p/cnetworkmanager I'd sure appreciate it. Thanks in advance.
[16:37] <persia> tsmithe: Kinda, but in the middle of three different things.
[16:37] <persia> tsmithe: I presume this is because I didn't actually upload musecore yet?
[16:37] <tsmithe> ok. pisa has just been uploaded to debian; i was wondering if it could be synced; how should i request that?
[16:37] <tsmithe> oh, and yeah :p
[16:37] <persia> tsmithe: File a sync request bug (requestsync is a good tool for this).
[16:37] <tsmithe> ok.
[16:38] <tsmithe> if it gets in before you upload musescore, hold on, and i'll make a new package which employs pisa to generate the offline manauls
[16:38] <tsmithe> *manuals
[16:38] <tsmithe> (do you think that's likely?)
[16:39] <persia> Let's do that as a bugfix later if it all works by feature-freeze.  Adding more coordination increases the risk of failure prior to that.
[16:39] <persia> I presume we can use the same orig.tar.gz?
[16:39] <tsmithe> that's what i thought
[16:39] <tsmithe> and yes
[16:40] <persia> Yeah, let's do it that way then: so we don't hit the wall in 21 hours.
[16:40] <persia> Err, 31 hours.
[16:41] <tsmithe> cool; i was just concerned that you'd "waste" an upload :)
[16:45] <tsmithe> persia, sync request done; thanks. it's bug 522718
[16:50] <mhall119|work> can someone point me to where I can learn about what a package branch is, and how it should be maintained?
[16:54]  * popey also has a question..
[16:55] <popey> I'm looking at packaging something which is mostly just a shell script and a few other support files - source only - is there a package in the repo that i could learn from in terms of debian/rules and debian/install ?
[16:58] <james_w> hi mhall119|work
[16:58] <james_w> https://wiki.ubuntu.com/DistributedDevelopment has some information
[16:58] <james_w> basically a package branch is just using bzr to do packaging
[16:59] <james_w> or indeed any other VCS
[16:59] <james_w> therefore it's basically using bzr, with a few extra commands layered on top for packaging-specific operations
[17:00] <james_w> popey: try ubumirror
[17:00] <popey> thanks
[17:00] <mhall119|work> thanks james_w
[17:00] <mhall119|work> trying to learn the right way of doing all this
[17:06] <hyperair> https://launchpad.net/~ubuntu-motu <-- "Ubuntu MOTU Developers does not use Launchpad ..."
[17:06] <hyperair> heheh
[17:13] <mhall119|work> ok, I'm making package for Qimo (https://launchpad.net/qimo), it has no upstream package, so what should I put in debian/watch to satisfy lintian?
[17:15] <hyperair> # lintian sucks
[17:16] <abogani> mhall119|work: IMHO You should explain it into debian/watch!
[17:16] <james_w> mhall119|work: if you make it a "native package" then lintian shouldn't complain
[17:17] <mhall119|work> james_w: what's the difference in a "native package"?
[17:17] <Laney> I'd just explain it in README.source or elsewhere
[17:17] <Laney> (I presume you are package as a snapshot)
[17:17] <jbernard> james_w: thanks for sync'ing liblua-iconv
[17:17] <mhall119|work> abogani: explain it how?  a # comment?
[17:17] <hyperair> yeah, a # comment
[17:17] <mhall119|work> Laney: I'm the original developer
[17:17] <james_w> mhall119|work: it's a package that is only intended for Debian-based systems, and so doesn't have an upstream releasing tarballs etc.
[17:17] <Laney> mhall119|work: can't you make a release?
[17:19] <mhall119|work> Laney: you mean just a tarball?
[17:19] <Laney> sure
[17:19] <mhall119|work> it has to copy files into /etc/xdg, /etc/X11 and /usr/share
[17:19] <mhall119|work> could I do that with just a tarball?
[17:20] <mhall119|work> the project is hosted on launchpad
[17:21] <mhall119|work> james_w: how do I make a native package?
[17:21] <james_w> a release can just be making a tarball from your bzr branch
[17:21]  * mhall119|work hasn't a bzr branch
[17:22] <mhall119|work> which is why I was asking about making package branches
[17:22] <james_w> however, if there is no reason why anyone would use it outside of Ubuntu then you can just make a native package
[17:22] <mhall119|work> ok, how do I make a native package?
[17:22] <james_w> which you just do by changing the version number to have no "-" in it, so if it's 1.0-0ubuntu1 currently just make it 1.0
[17:22] <mhall119|work> oh, ok, I'll try that
[17:24] <mhall119|work> I get this warning:
[17:24] <mhall119|work> W: qimo-wallpaper: latest-debian-changelog-entry-changed-to-native
[17:24] <mhall119|work> is that okay?
[17:28] <james_w> mhall119|work: that sounds like lintian trying to protect you, but yeah, that's what you intend
[17:31] <mhall119|work> james_w: could you have a look: http://revu.ubuntuwire.com/details.py?upid=7831
[17:31] <mhall119|work> it says it has no .orig.tar.gz, but it's in the file list
[17:39] <persia> hyperair: Just FYI, there's a bit of a technical glitch: you'll be a MOTU soon.
[17:40] <hyperair> persia: okay. take your time =)
[17:45] <DmitryKurochkin> Looking for a second advocate for polygraph package - http://revu.ubuntuwire.com/p/polygraph. Can somebody review it, please?
[17:47] <bdrung_> can one motu have a look at yofrankie: http://revu.ubuntuwire.com/details.py?upid=7812
[17:47] <sebner> bdrung_: uhh, you will win the money :D
[17:48]  * hyperair clicks
[17:53] <hyperair> DmitryKurochkin: the current policy version is <IP_ADDRESS>
[17:56] <DmitryKurochkin> hyperair: lintian compleined about it (I suppose it was not updated), so I uploaded with standards-version 3.8.3. No problem to update it again, no changes required.
[17:58] <hyperair> DmitryKurochkin: this is more of an aesthetic thing, but were the last two lines of debian/copyright intentionally wrapped like that? it looks like premature wrapping
[17:59] <hyperair> DmitryKurochkin: "Documentation, test results, ... available at www.web-polygraph.org" <-- i think you should put the http:// there
[18:01] <lightnin> Please help: I've got a programming language for kids called "Scratch" developed at MIT Media lab that I'm trying to get into multiverse. Needs to be revu 'ed..
[18:01] <DmitryKurochkin> hyperair: wrapping in debian/copyright is intentional, "see" can be moved to the previous line but the file name will have to stay on the second line anyway.
[18:01] <lightnin> http://revu.ubuntuwire.com/p/scratch
[18:02] <hyperair> DmitryKurochkin: ah i see.
[18:04] <DmitryKurochkin> hyperair: I would prefer to leave www.web-polygraph.org without http:// in the description. I think it looks better without http:// in sentences, and better with http:// in tables, etc.
[18:04] <hyperair> hmm
[18:04] <DmitryKurochkin> hyperair: it is a subjective thing, but if there is a policy on it, or recommended style, I will change it.
[18:05] <hyperair> i don't think there's a policy on it, nor do i know if it's a recommended style, but i prefer to have the http:// there, due to strange issues that can arise from stuff ripping out descriptions and linkifying stuff on web pages
[18:06] <hyperair> you know, without the http://, www.web-polygraph.org linkified would end up as http://the-site-you-saw-this-at.com/www.web-polygraph.org which would likely yield 404
[18:06] <randomaction> hyperair: congrats!
[18:06] <hyperair> randomaction: thanks!
[18:08] <hyperair> DmitryKurochkin: that said, i think having the url in the description again is kind of redundant since it's in the Homepage: field. i think it would be better to rephrase the description to remove the url, if possible.
[18:08] <DmitryKurochkin> hyperair: that is not true, take a look at http://revu.ubuntuwire.com/p/polygraph
[18:08] <DmitryKurochkin> it is linked to http://www.web-polygraph.org./ there.
[18:09] <DmitryKurochkin> that is not correct, but http:// would not help here
[18:09] <hyperair> DmitryKurochkin: that's REVU. what about other not-known, crappily-written, not-well-maintained utilities out there that also rip out descriptions from packages?
[18:10] <hyperair> but then again i know of any such utility out there
[18:10] <hyperair> it isn't a major issue, just more of me nitpicking
[18:12] <hyperair> DmitryKurochkin: oh yeah, one more thing.. your debian/copyright is fine as is, but it'd be better if you could follow http://dep.debian.net/deps/dep5/ in the future.
[18:12] <DmitryKurochkin> I can fix it if you insist, removing the link is a better option perhaps.
[18:13] <DmitryKurochkin> hyperair: yes, I have seen dep5 (after I packaged polygraph) and liked the idea. But I hope we can leave copyright as is for the initial upload and fix it later.
[18:13] <hyperair> it's completely up to you. i'd advocate/upload it as is (when my advocating/uploading privileges arrive) already.
[18:15] <DmitryKurochkin> hyperair: thanks! I was worried that I miss the deadline.
[18:16] <lightnin> Is appropriate control file entry for Section: multiverse/devel when submitting to multiverse?
[18:16] <hyperair> oho FF is tomorrow.
[18:17] <sebner> hyperair: that'll be a tough night your you then :P
[18:17] <sebner> *for
[18:17] <DmitryKurochkin> Isn't it on February 18?
[18:18] <hyperair> DmitryKurochkin: it's 17th here.
[18:18] <hyperair> i'll go get some sleep
[18:18] <hyperair> hopefully my uploading privileges arrive when i wake.
[18:18] <oojah> I'm looking for a second advocate for sqlite3-pcre can anybody help?
[18:18] <hyperair> sebner: or do you want to handle this?
[18:18] <DmitryKurochkin> Ihyperair: hope they do :)
[18:18] <hyperair> =)
[18:19] <sebner> hyperair: I'm working on quite some packages right now, so I didn't read your dicussion. what's it about?
[18:19] <hyperair> sebner: polygraph
[18:19] <hyperair> http://revu.ubuntuwire.com/p/polygraph
[18:20] <sebner> hyperair: urgh, I usually don't upload any cdbs packages (lack of knowledge) :P but I'll take a look later and upload it if nobody steps up first
[18:21] <hyperair> sebner: heheh don't worry, that cdbs package is very simple. just three lines.
[18:21] <hyperair> make that 4, with the #!
[18:22] <sebner> hyperair: yeah, so I'm making a special exception for you :P
[18:22] <hyperair> heheh
[18:23] <sebner> what about these spelling warnings?
[18:23] <hyperair> oh yeah, i think it'd be better if it could be patched up =\
[18:24] <sebner> + Standards-Version
[18:24] <DmitryKurochkin> sebner: it will be fixed in the next upstream release.
[18:24] <hyperair> but spelling errors are completely an upstream thing.
[18:24] <sebner> DmitryKurochkin: well, you certainly won't be able to upload a new upstream version (except bugfix only) but such a thing is no stopper bug for now
[18:31] <james_w> mhall119|work: sorry, got distracted. Where did qimo-session_2.0.0.orig.tar.gz come from?
[18:32] <mhall119|work> I just created a tarball of what I was trying to package
[18:32] <james_w> but you don't want to do that in future as an extra step?
[18:33] <mhall119|work> huh?
[18:33] <mhall119|work> I don't understand what you're asking
[18:34] <james_w> we were discussing earlier about whether there was an upstream that does releases
[18:34] <mhall119|work> oh, right
[18:34] <james_w> in effect that is what you did by creating that tarball, so you can continue doing it
[18:34] <mhall119|work> debuild wanted a .orig.tar.gz, so I just make one to make it happy
[18:34] <mhall119|work> ok
[18:34] <james_w> ok
[18:34] <mhall119|work> so is a package branch just a bzr branch of that tarball's content?
[18:35] <james_w> you can just delete it now that you have changed the version number, rebuild and then re-upload and the warning will go away
[18:35] <mhall119|work> or does the branch need to contain the tarball, plus the files it contains?
[18:35] <james_w> or rather, will be less confusing as it won't contradict what is clearly there
[18:35] <mhall119|work> oh, it was only necessary because it wasn't a native package before?
[18:35] <james_w> yeah
[18:35] <mhall119|work> ok, cool, thanks
[18:36] <mhall119|work> do I need to do that now, or is it okay as is?
[18:36] <james_w> debuild said (paraphrasing) "your version number suggests this package should have upstream releases, but you didn't give one of them too me, please do so"
[18:36] <mhall119|work> right, before I changed the version number, makes sense now
[18:36] <james_w> the content will be the same, so there's no real need
[18:36] <mhall119|work> I thought it still needed it to create the diffs
[18:36] <james_w> but if you don't then someone else will probably have this same conversation with you again :-)
[18:37] <james_w> it would, but if you do a native package then there is no upstream to create diffs against
[18:37] <mhall119|work> ok
[18:37] <james_w> it just puts everything in one tarball
[18:40] <lightnin> Please, oh mighty MOTUs: http://revu.ubuntuwire.com/p/scratch
[18:41] <mhall119|work> hey, that takes care of needing a debian/watch file too
[18:41] <mhall119|work> hey lightnin
[18:46] <highvoltage> for packages that contain cc-by-sa work, the full license needs to be included in the debian/copyright file, right?
[18:47] <james_w> highvoltage: yes
[18:48] <quadrispro> hello folks!
[18:48] <sebner> hio quadrispro
[18:48] <quadrispro> does REVU support debian 3.0 (quilt) format?
[18:48] <quadrispro> hi sebner
[18:49] <highvoltage> thanks james_w
[18:49] <sebner> quadrispro: nope
[18:49] <mhall119|work> james_w: how could it be included?
[18:49] <mhall119|work> a link?
[18:49] <quadrispro> :-(
[18:49] <sebner> quadrispro: well, you can upload stuff but you can review it with your browser
[18:50] <mhall119|work> a debian/CC-BY-SA file?
[18:50] <highvoltage> mhall119|work: full text inside the copyright file
[18:50] <quadrispro> sebner, thank you
[18:50] <james_w> mhall119|work: verbatim
[18:50] <sebner> quadrispro: *can't review I men
[18:50] <sebner> *mean
[18:50] <sebner> *arggh*
[18:50] <mhall119|work> is it okay to keep the GPLv2 in debian/COPYING?
[18:54] <mhall119|work> james_w: highvoltage: I'm uploading new packages now
[18:54] <lightnin> Hiya mhall119|work
[18:54] <mhall119|work> highvoltage: are you reviewing the latest?
[18:55]  * abogani is converting to 3.0 (quilt) and find it very cool!
[18:55] <mhall119|work> cause I fixed those warnings in your comment a while ago
[19:04] <oojah> bdrung_: You looked at sqlite3-pcre yesterday. Would you have another look today? I could do with a second advocate.
[19:06] <highvoltage> mhall119|work: I think -wallpapers will be ok now
[19:08] <mhall119|work> thanks highvoltage
[19:08] <mhall119|work> bbl, going to get some lunch, then to work on Qimo 2 Alpha 2 ISO
[19:11] <highvoltage> mhall119|work: ok give me a ping when you're back
[19:21] <Genscher> hey :) i am creating an ubuntu package and wondering where to install non-shared application data where I need read + write access.
[19:22] <Genscher> I just don't know the ubuntu way on this. Is it $HOME/.application ?
[19:22] <Genscher> or /var/lib/application
[19:30] <lightnin> I'm trying to add a programming environment for kids called Scratch - developed at MIT Media lab. We've recently submitted to REVU, please take a look: http://revu.ubuntuwire.com/p/scratch
[19:34] <randomaction> Genscher: maybe you're looking for this? http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[19:35] <Genscher> randomaction, indeed I think i am :)
[19:36] <lightnin> Is this an appropriately formatted "original maintainer" line? XSBC-Original-Maintainer: Scratch Team<EMAIL_ADDRESS>[19:37] <lightnin> I found it here: https://wiki.ubuntu.com/…iew#The%20control%20file
[19:38] <lightnin> But Lintian doesn't like it: W: scratch source: unknown-field-in-dsc original-maintainer
[19:46] <mhall119|work> highvoltage: did you look over the scratch package?
[19:48] <highvoltage> mhall119|work: no, I lost my browser session yesterday!
[19:51] <highvoltage> mhall119|work: I think -session will also be fine
[19:55] <mhall119|work> highvoltage: http://revu.ubuntuwire.com/p/scratch if you wouldn't mind
[20:06] <sebner> DmitryKurochkin: uploaded. I updated the Standards-Version. I'm a little bit worrying about the source files because not a single one contains a license header but that's up to the archive-admins to decide
[20:08] <DmitryKurochkin> sebner: thanks. What happens if archive-admins reject it after the freeze? Will I have a chance to fix and reupload the package?
[20:09] <sebner> DmitryKurochkin: that needs to be fixed upstream and I doubt it'll be reviewed until FF
[20:09] <sebner> DmitryKurochkin: which means *if* it gets rejected you might have to wait until lucid+1
[20:11] <Laibsch> Is do-release-upgrade not yet capable of a hardy -> lucid upgrade?
[20:11] <lifeless> no
[20:11] <lifeless> (gotta love double negatives)
[20:11] <DmitryKurochkin> sebner: what a proper license header should look like? License is mentioned in each source file currently, isn't that enough?
[20:12] <Laibsch> lifeless: when is that scheduled to change?
[20:12] <Laibsch> oops, wrong channel
[20:12] <Laibsch> I hope you don't mind, though
[20:13] <sebner> DmitryKurochkin: I'm not sure but using a full license header is common
[20:13] <jpds> Laibsch: He meant that it is.
[20:13] <sebner> DmitryKurochkin: see your copyright file (License:) but it might be enough as it's currently
[20:14] <Laibsch> jpds: I just tried "sudo do-release-upgrade -d" and it wants to update to intrepid
[20:15]  * Laibsch moves the discussion to ubuntu+1
[20:15] <Laibsch> sorry for initial off-topic
[20:15] <DmitryKurochkin> sebner: ok, I will wait and see. Where should I look at to know when package is accepted/rejected?
[20:16] <sebner> DmitryKurochkin: I think you'll get a mail
[20:17] <DmitryKurochkin> ok. sebner, hyperair, fabrice_sp thanks for review and advocating!
[20:19] <fabrice_sp> kklimonda, ping (about picard)
[20:20] <kklimonda> fabrice_sp: pong
[20:20] <lifeless> Laibsch: oh, I see what you're asking. (Try to provide that additional detail in future ;). I suspect thats worth checking with e.g. mvo
[20:20] <Laibsch> lifeless: what additional detail?
[20:21] <lifeless> Laibsch: the behaviour you observe
[20:21] <fabrice_sp> package is good, but lintian is complaining about big usr/share independent files. What do you think about splitting the package in 2?
[20:21] <fabrice_sp> kklimonda, ^
[20:22] <kklimonda> fabrice_sp: I didn't really want to divert from debian more than necessary to update it. especially this close to the FF date
[20:23] <kklimonda> fabrice_sp: I agree that it should be split in two packages
[20:24] <lifeless> Laibsch: can you pastebin the output ? mvo is here about the d-r-u -d selecting intrepid thing
[20:24] <mvo> Laibsch: and ~/.update-manager-core/meta-release-lts-development too please
[20:25] <Laibsch> lifeless: you're saying you were just suspecting it works and would have been more careful had you understood more clearly that apparently it wasn't working (the way I asked the question should have been enough of a hint).  Maybe you should give a less affirmative statement ("I would think so") when you don't really know because you have not tried.
[20:25] <Laibsch> mvo: just a minute
[20:25] <Laibsch> mvo: you want to continue discussion here or in ubuntu+1?
[20:26] <fabrice_sp> kklimonda, that's also my concern. I'll upload it as-is. Could you contact the Debian maintainer about that?
[20:26] <Laibsch> mvo: no such file
[20:26] <lifeless> Laibsch: I'm saying I didn't even really understand the question; I thought you meant hardy->intreprid etc staged
[20:27] <Laibsch> lifeless: OK
[20:27] <lifeless> Laibsch: the additional detail of what actually happened when you tried made everything much clearer
[20:27] <Laibsch> I meant the straight hardy -> lucid update
[20:27] <kklimonda> fabrice_sp: sure - I'll do that
[20:27] <lifeless> yes, we're clear on that now ;)
[20:27] <fabrice_sp> kklimonda, thanks ;-)
[20:27] <lifeless> (its why I grabbed mvo :) - not being able to test this is a bit of an issue :))
[20:27] <mvo> Laibsch: hm, no file but "do-release-upgrade -d" was run? what is the output of "DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d"  ? could you pastebin that for me please?
[20:28] <Laibsch> mvo: OK, I will in a minute
[20:29] <Laibsch> the update aborted anyway because of insufficient space in /var.  I have /var on a separate 1G partition which is usually more than enough.  Is there something that can be done about this or are users like me on their own?  (I don't have a problem recovering from this, others may)
[20:29] <Laibsch> mvo: ^
[20:30] <lifeless> Laibsch: I thought it wasn't selecting lucid?
[20:31] <Laibsch> lifeless: it's selecting intrepid but aborting that update because of insufficient disk space
[20:32] <Laibsch> I have to say, I didn't mind because I don't want to take the long route ;-)  and I also want to use this single chance I have (last computer running hardy) to test for upgrade for the benefit of all.
[20:37] <mvo> Laibsch: the logs in /var/log/dist-upgrade/main.log will tell why it needs so much space. the download of the debs can be pretty heavy. if you can still reproduce theproblem that it selects intrepid instead of lucid, please put the debug output in a pastebin or mail it to me
[20:37] <Laibsch> It's currently running
[20:38] <Laibsch> So far, the system hasn't changed
[20:38] <mvo> ok
[20:43] <fabrice_sp> foolano, ping (about ebox)
[20:51] <Laibsch> mvo: Here it is: http://paste.debian.net/60079/  Not sure it contains much information, but you be the judge
[20:51] <bdrung_> fabrice_sp: can you have a look at http://revu.ubuntuwire.com/details.py?upid=7812 ? it depends on blender >= 2.49.2~dfsg aka 2.49b
[20:52] <Laibsch> mvo: let me know if you want anything from /var/log/dist-upgrade/ as well
[20:53] <fabrice_sp> bdrung_, looking now
[20:53] <fabrice_sp> 156 Mb?!
[20:53] <lifeless> Laibsch: is there a ~/.update-manager-core/meta-release-lts-development now?
[20:54] <lifeless> Laibsch: or /root/.update-manager-core/meta-release-lts-development ?
[20:54] <Laibsch> lifeless: neither
[20:55] <mvo> Laibsch: if you ran it with sudo, please check /var/lib/update-manager/
[20:55] <PATX> can i get some help with making a get-orig-source rule?
[20:55] <PATX> are there any tutorials?
[20:56] <Laibsch> PATX: I was looking for the same thing a while ago
[20:56] <PATX> Laibsch, :) did u find anything?
[20:56] <Laibsch> let me fetch what I did write after some googling
[20:56] <Laibsch> PATX: no
[20:56] <kklimonda> I need a helping hand with bug 482890 - it has to be ACK'd by someone who has supercow powers :)
[20:56] <PATX> ok thanks :)
[20:56] <Laibsch> PATX: it was piece work
[20:56] <kklimonda> it's actually a sync - stupid ubottu
[20:56] <PATX> yea...
[20:56] <Laibsch> PATX: but ultimately, it's not hard
[20:56] <Laibsch> hang on for a minute
[20:57] <PATX> i cant find any help either lol... ok ty
[20:57] <Laibsch> PATX: http://git.debian.org/?p=collab-maint/sqliteman.git;a=commitdiff;h=fabff284aa02e5a967ebdd142b18922b43f4a5fc
[20:57] <Laibsch> ask if you have any further questions
[20:57] <PATX> thanks dude :)
[20:57] <Laibsch> but I think that diff should be enough
[20:58] <Laibsch> Maybe I should write a short tutorial
[20:58] <Laibsch> I was missing it at the time
[20:59] <PATX> yea that would be a good idea
[21:03] <Laibsch> mvo: http://paste.debian.net/60084/ and http://paste.debian.net/60085/ being /var/lib/update-manager/meta-release(-development).  The latter does contain a lucid and the former has no intrepid.  So, I'm not sure what's happening there.
[21:04] <Laibsch> mvo: I'll file a wishlist bug about better handling of situations where space is tight.  Maybe there is something that can be done.  700MB-1G isn't always available in /var for your typical upgrade.
[21:08] <Laibsch> mvo: actually that could be as simple as augmenting the error message with the suggestions a-c) from https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/152580/comments/8
[21:09] <Laibsch> I'll see if I can come up with a patch
[21:09] <mvo> Laibsch: thanks
[21:11] <mvo> Laibsch: does "DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d" as a normal user give any hints? I just tried that in a hardy vm and it gives me useful output before the sudo prompt about what its doing
[21:11] <mvo> Laibsch: I'm still puzzled that it wants to upgrade you to intrepid
[21:11] <Laibsch> OK
[21:11] <Laibsch> I'll let that run
[21:11] <Laibsch> normal user, no sudo?
[21:11] <Laibsch> or
[21:11] <mvo> normal user
[21:11] <Laibsch> normal user, gaining root with sudo
[21:11] <Laibsch> OK
[21:11] <Laibsch> I'll leave out sudo
[21:11] <mvo> it will automatically ask for sudo
[21:12] <Laibsch> I see
[21:12] <mvo> yeah, please leave sudo out
[21:12] <mvo> it will call it when it needs it
[21:20] <dooooomi> hi, i'm looking for a second advocate for gtklick, a metronome for JACK, written in python: http://revu.ubuntuwire.com/p/gtklick
[21:28] <Laibsch> mvo: could it be that a line like "deb-src http://ubuntu.intergenia.de/ubuntu karmic main restricted universe" in sources.list throws the update-manager off course?
[21:28] <Laibsch> but even then the next logical step would be lucid and not intrepid
[21:29] <mvo> Laibsch: I doubt that, it looks at the lsb_release output to figure out what version you are on
[21:29] <mvo> Laibsch: nothing useful in the debug output?
[21:29] <Laibsch> OK
[21:29] <Laibsch> still running
[21:29] <Laibsch> it's a slow computer running as a LAN server
[21:29] <DmitryKurochkin> is there a web page where I can see what is in Ubuntu NEW queue? similar to http://ftp-master.debian.org/new.html?
[21:29] <mvo> ok
[21:29] <Laibsch> I'll let you know when it's done and give you the pastebin
[21:32] <Laibsch> mvo: just as we spoke, the program finished: http://paste.debian.net/60091/  and the file you've been asking about is still not there
[21:33] <Laibsch> JFTR, update-manager is the version from hardy-updates
[21:33] <Ubuntuxer> Hi, is it possible to update the exaile package for Lucid yet?
[21:34] <cjwatson> sebner: I'm told that mvo is taking care of it
[21:35] <cjwatson> (dpkg)
[21:35] <lifeless> Laibsch: mvo: fwiw on my hardy server:
[21:35] <lifeless> DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d
[21:35] <lifeless> ...
[21:35] <lifeless> authenticate 'lucid.tar.gz' against 'lucid.tar.gz.gpg'
[21:35] <Laibsch> interesting
[21:35] <lifeless> so its choosing lucid.
[21:35] <Laibsch> thanks for testing
[21:37] <mvo> cjwatson, sebner if we can find someone who enjoys perl more than me I would not mind at all to not do it (dpkg)
[21:38] <mvo> lifeless, Laibsch: same for me in my vm (chosing lucid)
[21:38] <mvo> Laibsch: I need to go to bed soon, can we continue debugging tomorrow?
[21:38] <Laibsch> probably
[21:38] <Laibsch> just try to catch me anytime
[21:39] <Laibsch> I may not be in this channel and I don't run this nick 24/7, but I'm frequently in IRC
[21:39] <lifeless> perhaps file a bug
[21:39] <Laibsch> yeah
[21:39] <cjwatson> mvo: I am happy to do it at some point this week, despite holiday; it shouldn't be hard
[21:40] <cjwatson> mvo: in fact the perl bits of the existing hardy-cat patch apply cleanly, with only a one-line offset
[21:40] <mvo> cjwatson: oh? I must have done something wrong then, when I briefly looked at it, the patch gave me loads of rejects
[21:41] <Laibsch> mvo: one thing that may be different in my installation than on others; I have so far always used aptitude for upgrading to a new release.  It's the first time I use update-manager for it.
[21:41] <mvo> probably some wrong version or something
[21:41] <Laibsch> But it's quite possible that this machine never ran anything but hardy
[21:41] <Laibsch> I don't remember
[21:41] <cjwatson> mvo: lots of rejects, but not in the perl bits, afaics
[21:41] <cjwatson> the man/Makefile.{am,in} changes can be dropped
[21:41] <mvo> Laibsch: that should be ok, lsb_release -a gives you hardy there, right?
[21:42] <Laibsch> yepp, it does
[21:42] <cjwatson> mvo: although I think the Dpkg::Vendor changes may need some tweaks anyway
[21:43] <Laibsch> http://paste.debian.net/60096/ is the full output
[21:46] <mvo> Laibsch: hm, shold be fine. lets continue tomorrow
[21:46]  * mvo waves
[21:46] <Laibsch> sure
[21:46] <Laibsch> thanks
[21:46] <Laibsch> good night
[21:46] <mvo> cjwatson: thanks, I can check it out tomororw, also FF is pretty pressing currently :/
[22:11] <PATX> can someone tell me what the first problem on this page means? http://revu.ubuntuwire.com/revu1-incoming/fastpatx-1002160248/lintian
[22:16] <PATX> i am not getting this i thought i defined this in debian/control...
[22:16] <PATX> Build-Depends: cdbs (>=0.4.49), debhelper (>= 5), python-central (>=0.5.6), python
[22:16] <PATX> debhelper (>= 5)
[22:17] <PATX> ^^^
[22:17] <geser> what value is in debian/compat?
[22:17] <PATX> checks
[22:17] <POX> 7
[22:17]  * POX knows without looking
[22:17] <PATX> 2
[22:18] <PATX> oh...
[22:18] <POX> that's debian/pycompat
[22:18] <PATX> oh
[22:18]  * POX knows without looking
[22:18] <POX> ;)
[22:18] <PATX> yea
[22:18] <PATX> lol
[22:18] <PATX> i dont have a compat...
[22:18] <PATX> should i make one and put 7 in there?
[22:18] <PATX> would that solve problem?
[22:19] <PATX> oh wait nvm
[22:19] <PATX> i have compat
[22:20] <PATX> geser, so the value is 7 now...?
[22:22] <Laibsch> some kind MOTU soul around to review (and hopefully endorse) http://revu.ubuntuwire.com/p/ffgtk ?
[22:22]  * Laibsch is hopeful
[22:23] <Laibsch> porthose?
[22:23] <geser> PATX: depends on what debhelper level you want to use
[22:23] <PATX> geser, 5...
[22:23] <PATX> debhelper (>= 5)
[22:24] <PATX> oh should there be a space there... does it matter?
[22:24] <geser> than put 5 in debian/compat
[22:24] <PATX> ah ok
[22:24] <PATX> debhelper (>= 7)
[22:24] <PATX> or should i use that?
[22:25] <sebner> PATX: you can use it when you delete cdbs and update rules accordingly ;)
[22:25] <PATX> ok
[22:25] <PATX> and then the error:
[22:25] <PATX> W: fastpatx source: native-package-with-dash-version
[22:26] <PATX> how could i fix that?
[22:26] <Laibsch> PATX: google for the error string
[22:26] <PATX> ok
[22:26] <Laibsch> you will usually find plenty of info for lintian errors
[22:26] <RAOF> Also, lintian -i (or -I, I forget precisely which) will give you a big block of text about each error, which usually includes how to fix it.
[22:27] <porthose> Laibsch, I'm busy working on something right now, maybe later if I have time :)
[22:28] <Laibsch> porthose: I'd really appreciate it.  We already missed karmic, I don't want to miss Lucid again.
[22:29] <RAOF> Laibsch: I can give a brief once-over.  Looking at the diff of ffgtk, you've modified a bunch of files from the .orig.tar.gz directly; that would usually be done in a patch with a patch system, although if you're maintaining it in git it can be a bit different.
[22:30] <RAOF> Laibsch: Do you really need the explicit Depends on libgtk2.0-0, libxml, etc?  Why aren't they picked up in ${shlibs:Depends}?
[22:32] <RAOF> Laibsch: Is the packaging already in collab-maint git?  What's the status with its ITP in Debian?
[22:32] <Laibsch> RAOF: package maintenance will be in git (as for all my packages).  You're right, the patches should eventually be in a patch system, dpkg v3 is looming.  The things you raise are likely legacy from the person who did the first draft of the packaging.
[22:33] <Laibsch> I'm sure I already pushed this to git.debian.org
[22:33] <Laibsch> There is no ITP, yet, I'm shooting for inclusion in lucid now and that keeps me busy enough
[22:34] <Laibsch> eventually, I intend to maintain this (as my other packages) in Debian since that is best for Ubuntu, Debian and just everybody.
[22:34] <RAOF> Yup.
[22:34] <Laibsch> but even under best circumstance, this won't hit Debian before the summer
[22:34] <lifeless> its summer now
[22:34] <Laibsch> depends on where you are
[22:34] <Laibsch> ;-)
[22:34] <RAOF> Before *next* summer :P
[22:35] <lifeless> I suggest never ever ever using seasonal terms in global endeavours
[22:35] <Laibsch> well, I'd say, even for you, summer is coming to an end
[22:35]  * Laibsch is feelling springy
[22:36] <Laibsch> lifeless seems to be a little nit-picker, hm?
[22:36]  * ScottK looks outside at three feet of snow on the ground and is not.
[22:36] <ScottK> (feeling springy)
[22:36] <sebner> ScottK: great for staying at $HOME and updating stuff like crazy before FF :)
[22:37] <ScottK> sebner: Fortunately none of it came in the last week, so I'm not trapped.
[22:37] <ScottK> School finally resumes tomorrow.
[22:37] <lifeless> Laibsch: sometimes perhaps. However it really does introduce confusion to say 'summer' or 'winter' in IRC/email etc.
[22:37] <lifeless> it requires more context for recipients at a minimum
[22:37] <RAOF> Laibsch: While my pbuilder is hard-a-work grabbing build-depends, I'd also suggest that you'd want to make an explicit call to autoreconf rather than relying on automake to see the right timestamps.
[22:38] <Laibsch> RAOF: I will check that the dependencies are really necessary. git.debian.org will be updated with git-import-dsc once it has hit either Ubuntu (hoping for the best) or Debian, whichever comes first.  Can you give an endorsement once the dependencies have been double-checked?
[22:38] <lifeless> I don't think its nitpicky to point this out and suggest that its better not to do it.
[22:38] <sebner> ScottK: Everytime I read that or see that in TV (your phrase about school) it makes me kinda feel that parents are happy to get their children out of the house ^^
[22:39] <ScottK> Kinda does not even begin to cover it.
[22:39] <sebner> heh
[22:39] <Laibsch> RAOF: you kind of lost me with that autoreconf.  I'm not a buildmaster, some dummy tutorial somewhere?
[22:40] <Laibsch> RAOF: I promise to fix the issues you raised.  I hope they are not serious enough to block inclusion from lucid and would hope for an endorsement.
[22:40] <RAOF> Laibsch: Ah, well.  You modify configure.ac & Makefile.am (somewhat unnecessarily, but it'll be nice when you submit that patch upstream); this won't actually have any effect unless configure & the various Makefile.in files are regenerated.
[22:40] <Laibsch> that's been done by the guy who actually understands that stuff ;-)
[22:42] <RAOF> Ah.  Your package doesn't build.  Or, rather, it doesn't error but no build system is actually called, so you end up with an empty package.
[22:42] <oojah> Would a motu consider looking at http://revu.ubuntuwire.com/p/sqlite3-pcre ? I'm in need of a second advocate.
[22:43] <RAOF> Oh, of course.  This would be because you don't *have* a configure script, or a Makefile.
[22:43] <RAOF> You probably want an override_dh_auto_configure: target, calling ./autogen.sh
[22:43] <Laibsch> ?
[22:43] <Laibsch> it built fine for me
[22:43] <Laibsch> Are you testing the latest version?
[22:44] <RAOF> Did you build it in a pbuilder, from the source package you uploaded to revu?
[22:44] <Laibsch> http://revu.ubuntuwire.com/details.py?upid=7845
[22:44] <Laibsch> pbuilder
[22:44] <Laibsch> or in this case pdebuild
[22:44] <Laibsch> yes
[22:45] <RAOF> Hm.  Upstream needs to learn to run “make distcheck”.
[22:45] <Laibsch> let me retry, check the depends and ping you after that
[22:45] <Laibsch> thank you for your input
[22:45] <RAOF> It's not the depends that are the problem.
[22:45] <Laibsch> I know
[22:45] <Laibsch> But you raised it and I want to check
[22:45] <Laibsch> "in einem Aufwasch"
[22:45] <Laibsch> "while I'm at it"
[22:46] <RAOF> Also - where are you getting ffgtk 0.7.91?  The tarballs I can find on your upstream link are for 0.7.3
[22:46] <Laibsch> there's a watch file?
[22:46] <Laibsch> there's a watch file ;-)
[22:46] <Laibsch> Let me take a look
[22:47] <Laibsch> http://www.tabos.org/ffgtk/download/
[22:47] <RAOF> True.  It's just not linked from http://www.tabos.org/ffgtk/download.php
[22:50] <Laibsch> no
[22:50] <Laibsch> I'm working closely with upstream
[22:50] <Laibsch> and that tarball was done on my request ;-)
[22:50] <RAOF> Aaah.  Tell them to run “make distcheck” :)
[22:50] <Laibsch> it's also tar.gz and not .bz2
[22:50] <Laibsch> OK
[22:50] <Laibsch> I will
[22:51] <RAOF> Yeah, I noticed that.  With source v3 .bz2 would be fine, but .tar.gz will be more easily backportable.
[22:51] <Laibsch> As you can see on revu, I was aiming for inclusion in karmic
[22:51] <Laibsch> and AFAIK, dpkg v3 wasn't yet widely used back then
[22:52] <Laibsch> I've only become aware of it very recently
[22:52] <Laibsch> (and spent some time getting my hardy build host to understand dpkg v3)
[22:52] <Laibsch> notice about "make distcheck" sent
[22:52] <bcurtiswx> http://paste.ubuntu.com/377966/  anyone know what package i may be missing?
[22:54] <Laibsch> bcurtiswx: cdbs
[22:55] <Laibsch> look at lines 12-14
[22:55] <Laibsch> install apt-file and then you can search for the package that has the file in question
[22:55] <Laibsch> in this case, that's cdbs
[22:55] <bcurtiswx> Laibsch: ty
[22:56] <Laibsch> Interesting to see this question from somebody with @ubuntu.com ;-)
[22:56] <bcurtiswx> Laibsch: i got my membership mainly from my bug triage abilites
[22:56] <Laibsch> nice
[22:57] <bcurtiswx> Laibsch: im trying to see if I can backport empathy for karmic
[23:11] <bcurtiswx> not to be annoying or seem noob-ish.. but anyone know what I do to fix this problem http://paste.ubuntu.com/377979/
[23:16] <Laibsch> RAOF: you're right, I get an empty package, now too
[23:17] <Laibsch> not sure, why it was working nicely before.
[23:17] <RAOF> You had probably run ./autogen.sh in there at one point.
[23:19] <geser> bcurtiswx: either check if your empathy backport work with the versions of the mentioned packages from karmic or backport them too
[23:21] <bcurtiswx> geser, ok
[23:21] <bcurtiswx> geser: trying to find which packages these are
[23:22] <geser> bcurtiswx: line 180-183 of your paste
[23:25] <geser> the source packages are: telepathy-glib, libindicate and nautilus-sendto
[23:28] <bcurtiswx> geser: ty
[23:30] <plars> anyone have time to adv/upload a package (assuming you approve)? I already have one adv
[23:30] <plars> http://revu.ubuntuwire.com/p/moserial
[23:31] <Laibsch> RAOF: can I get an endorsement from you even when not addressing all points (collab-maint, patch-system, ITP)?  The others I consider RC and will of course fix.  I'm quite embarassed about that empty package.
[23:58] <bcurtiswx> geser: as I keep going back and finding packages to backport to get empathy to build ok.. how do I install them to pbuilder if they build OK so the next package can use it to build ?


[04:20] <wallyworld> tlm: or hpidcock: or kelvinliu: a small constraints PR https://github.com/juju/juju/pull/12020
[04:27] <hpidcock> wallyworld: looking
[04:45] <kelvinliu> wallyworld: got this pr for adding priority and priority, could u take a look plz https://github.com/juju/juju/pull/12022  thanks
[04:46] <wallyworld> i cam
[04:46] <kelvinliu> also tested updateStrategy
[04:49] <wallyworld> kelvinliu: lgtm, tyvm
[04:51] <kelvinliu> wallyworld: as i can see, i tested updatestrategy working as expected, im not sure why cory got that parsing error, probably he wasn't using 2.8+?
[04:51] <wallyworld> kelvinliu: yeah, i believe he was using 2.8.1 or something
[05:14] <kelvinliu> tlm: https://github.com/juju/juju/pull/12015 got this pr for caas firewaller worker for embedded apps, there are a few todos in the pr will be implemented in following prs, could u take a look plz? thanks
[05:25] <wallyworld> looking
[05:41] <wallyworld> kelvinliu: lgtm with a question about the api calls
[05:44] <kelvinliu> wallyworld: right, I will change the CharmInfo(url string) to CharmInfo(appName string)
[05:45] <wallyworld> ty
[05:46] <kelvinliu> thx for reviewing
[08:02] <taohansen> I'm trying to wrap my head around Juju: is Juju Charmed Kubernetes? Why would I want Juju over microk8s? Juju can consume microk8s to make a Juju cloud but I don't know specifically why I would want to do this. "A cloud is a target that Juju knows how to manage workloads for. " But Kubernetes is already a tool for managing workloads across pods and nodes.
[08:02] <taohansen> It looks like Charms are equivalent to Helm Charts. Is this a fair assumption?
[08:24] <icey> that's a new one: `Create instance: Invalid devices: Device validation failed "eth1": Invalid value for device option "mtu": Out of MTU range (1280-9202) "9214"`
[10:03] <stickupkid> manadart, fixes the documentation issue https://github.com/juju/juju/pull/12023
[10:04] <manadart> stickupkid: Nice.
[10:04] <stickupkid> not like me to miss documentation :|
[10:30] <achilleasa> stickupkid: yet another one... cursed yaml! https://github.com/juju/bundlechanges/pull/70
[10:46] <achilleasa> stickupkid: small fix for an NPE in charm that I discovered while testing: https://github.com/juju/charm/pull/320
[10:55] <manadart> stickupkid: Small one - https://github.com/juju/juju/pull/12024. achilleasa, having trouble with my Microstack; wanted to get this one up before a reboot. Be back on your review presently.
[10:56] <achilleasa> manadart: did you get it to work out of the box with snap?
[10:56] <achilleasa> I had to use the edge with --devmode and add an ip to get it to init
[10:57] <stickupkid> achilleasa, https://github.com/juju/juju/pull/11253/files#diff-a86032d7aeab77815b81f23cdfb46921
[10:58] <achilleasa> stickupkid: I also had to "ip add X <IP_ADDRESS>" to allow it to find rabbit
[11:11] <manadart> achilleasa: Yeah, I had the same issue. No change from when it was last working, but I lost the device addresses.
[11:12] <manadart> Then I hung on configuring the bootstrap machine...
[11:12] <manadart> Back up all fresh, see how it goes.
[11:16] <achilleasa> manadart: if you set up spaces and stuff please also try the last step in the QA (moving subnets)
[11:17] <manadart> achilleasa: Yeah, I was also going to delete a space. How would that go?
[11:22] <achilleasa> it should also work because the space-id in the subnets collection will change
[11:22] <achilleasa> and it will trigger a refresh of the rules
[12:44] <achilleasa> stickupkid: just pushed the PR for including expose settings in diff-bundle output. If you 've got some spare time can you take a look at https://github.com/juju/juju/pull/12025?
[12:44] <stickupkid> won't be till after standup tbh
[12:45] <achilleasa> not in a rush. just wanted to get all remaining chunks of work up for review today as next week I won't be able to work on this
[12:46] <achilleasa> that's the last PR though. Now I need to write a discourse post about it :D
[13:29] <stickupkid> manadart, fixes your issue with acceptance tests https://github.com/juju/juju/pull/12026
[13:44] <jam> Quick review of 2.8 into develop ? https://github.com/juju/juju/pull/12027
[14:35] <stickupkid> hml, so I've gone back to juju 2.0 and .Update has never been used to set a charm 4ddfc7da4fa771621e5f2a87492e1c6e6f068675
[14:36] <stickupkid> hml, so it was probably used for something, but not sure what tbh
[14:36] <stickupkid> hml, maybe future planning?
[14:40] <hml> stickupkid:  no idea…. maybe it was a juju 1 ism?
[14:40] <stickupkid> hml, I just wanted to be sure, but we're all good
[14:41] <hml> stickupkid:  +1
[14:47] <hml> stickupkid:  have we done any upgrade juju testing on the charm origins?
[14:47] <stickupkid> hml, not for a long time
[14:47] <stickupkid> hml, we should do that
[14:48] <hml> stickupkid:  same thoughts
[14:49] <stickupkid> hml, in theory https://github.com/juju/juju/blob/develop/state/upgrades.go#L3108
[14:49] <hml> :-)


[07:07] <dpm> zbenjamin, morning. Quick question: Qt Creator does no longer start for me on 16.04 - when launching it from the terminal it shows me this input, but it just hangs forever there, not even the launcher icon is shown -> http://paste.ubuntu.com/16060302
[07:07] <dpm> any ideas what it could be?
[07:07] <dpm> I've tried reinstalling 'ubuntu-sdk-ide', but no luck
[07:08] <zbenjamin> dpm: huh, thats weird. Even if some detection script would not return , none of it is blocking the main loop. So the QtC always should come up
[07:08] <zbenjamin> dpm: did you try to reset your settings?
[07:09] <dpm> zbenjamin, not yet, how do I do this?
[07:09] <zbenjamin> dpm: basically mv or rm ~/.config/QtProject/qtcreator
[07:14] <dpm> zbenjamin, that definitely made it happier. It could start, I ran the first run wizard and then it froze
[07:14] <dpm> let me try to start it again
[07:17] <zbenjamin> dpm: weird, do you maybe have any scripts / tools running forever?
[07:18] <dpm> zbenjamin, hm, now whenever I start it I can see the icon in the launcher, but it shows no UI. Let me start it from the terminal to see
[07:19] <dpm> zbenjamin, same messages as before: http://paste.ubuntu.com/16060383
[07:20] <zbenjamin> dpm: can you maybe see any scripts that would run forever?
[07:20] <dpm> with the only difference that now a Qt Creator icon is shown in the launcher, but still hangs forever. Clicking on the icon does nothing.
[07:21] <dpm> zbenjamin, not sure what to look for in terms of running scripts
[07:21] <zbenjamin> dpm: hm my cli skills with that are not too good , i usually use "ps auxwff" to show the ps tree and check if the qtc started any subprocesses
[07:22] <zbenjamin> dpm: or you get the pid for qtc and run pstree <pid>
[07:23] <dpm> zbenjamin, sure: http://paste.ubuntu.com/16060399
[07:24] <zbenjamin> dpm: ok, you have a lot of qtc instances running, maybe a "killall qtcreator" first until they are all gone
[07:24] <zbenjamin> dpm: then we try again
[07:25] <dpm> zbenjamin, that seemed to fix it, thanks! Let me test if everything is working...
[07:26] <zbenjamin> dpm: *crosses fingers*
[07:26] <zbenjamin> dpm: if you just moved your settings dir away, you can try to restore it and see if it works with your old settings
[07:27] <zbenjamin> dpm: then you will still have all your sessions and kits. Otherwise all project setup is gone
[07:27] <dpm> ah, good idea, yes, I just moved it
[07:29] <dpm> zbenjamin, I think I'll start anew. One think I noticed is that I don't have a "Desktop" kit, which previously was marked as "autodetected". Do I need to create one manually?
[07:30] <zbenjamin> dpm: hm normally it should be picked up automatically if you have a Qt and gcc installed locally
[07:30] <dpm> zbenjamin, http://i.imgur.com/cdwwBoe.png <- here is what I see
[07:31] <zbenjamin> dpm:  that is the old or new settings dir?
[07:31] <zbenjamin> also why the kits are marked ẃith an error, if you hover over it , it should show you the error message
[07:31] <dpm> zbenjamin, that's with the old settings dir. I've decided not to restore the old and start afresh. Not sure why it's showing a warning sign on the phone/emulator kits
[07:32] <zbenjamin> dpm: yeah something was definately broken then
[07:32] <dpm> zbenjamin, "Error: Mkspec not found for Qt version"
[07:32] <dpm> on hovering on a kit marked as warning
[07:32] <zbenjamin> dpm: hmm, and it works with the clean settings?
[07:33] <dpm> zbenjamin, not sure what you mean. I've only tried it with clean settings, and it doesn't work
[07:34] <zbenjamin> dpm: sorry then i got you wrong, i thought you see those errors only with the old settings dir and thats why you started fresh
[07:36] <dpm> zbenjamin, perhaps with so many instances running some where writing to the config at the same time? I've now deleted the *new* settings and restarted Qt Creator. Is the wizard supposed to show me this? http://imgur.com/jjcNwn5
[07:36] <zbenjamin> dpm: what does /home/dpm/.config/QtProject/qtcreator/ubuntu-sdk/ubuntu-sdk-15.04-armhf/qt5-qmake-arm-linux-gnueabihf -query   tell you
[07:37] <zbenjamin> dpm: that looks good
[07:39] <dpm> zbenjamin, making progress: Desktop kit available now (but not autodetected, marked as 'Manual'), but still errors on the phone/emulator kits -> http://imgur.com/j5wJ1Bi
[07:40] <dpm> zbenjamin, here's the output of the command: http://paste.ubuntu.com/16060459/
[07:41] <zbenjamin> dpm: hmm errr
[07:41] <zbenjamin> dpm: "click chroot -a armhf -f ubuntu-sdk-15.04 run qmake -query"
[07:42] <dpm> zbenjamin, same error as above
[07:42] <zbenjamin> dpm: ok , then something on the click level is broken ...
[07:42] <zbenjamin> dpm: did you upgrade / change anything on your system lately?
[07:43] <dpm> zbenjamin, I've been on Xenial on this computer for months, but I just upgraded to the sdk ppa (it had been disabled on the xenial upgrade) recently
[07:44] <dpm> zbenjamin, shall I just nuke the phone and emulator kits?
[07:44] <dpm> then rm the settings and start anew?
[07:44] <zbenjamin> dpm: that would be a possibility yes, but i'm afraid the bootstrapping won't work ...
[07:44] <dpm> oh, why?
[07:44] <zbenjamin> dpm: but then you can always use the static versions
[07:44] <zbenjamin> dpm: last time i checked one of the html packages broke it again. Maybe its fixed already since i did not hear any complaints
[07:45] <dpm> zbenjamin, I'm confused now. So what's "the right way" of having a phone kit? Static, non-static? Autogenerated on first Qt Creator start?
[07:45] <zbenjamin> dpm: the right way would be what the sdk does, bootstrapping it
[07:46] <zbenjamin> dpm: the static is just a workaround
[07:46] <dpm> and is there a way to force bootstrapping?
[07:46] <zbenjamin> dpm: no if the package dependencies are broken you can just use the static one
[07:46] <zbenjamin> dpm: we are working on a complete replacement for that mess
[07:46] <zbenjamin> dpm: we just started testing but it will still take some time until its ready for a beta that is useable enough
[07:47] <dpm> zbenjamin, ok. So what do you recommend I do with my current kits? Try to fix them or use the static versions? And in any case, what should I do as the next step?
[07:48] <zbenjamin> dpm: you need to nuke them definately. Then first try creating one on the way you always did. If that does not work i tell you how to install the static one
[07:49] <zbenjamin> dpm: if your kits get created you just use the SDK as usual
[07:49] <dpm> zbenjamin, ok, for starters, how can I remove them then?
[07:51] <dpm> zbenjamin, will the "Remove" button in the Options > Build & Run dialog take care of deleting everything?
[07:52] <zbenjamin> dpm: either in QtC using the options -> ubuntu  page, or easier on CLI :   click chroot -a armhf -f ubuntu-sdk-15.04 destroy   and  click chroot -a i386 -f ubuntu-sdk-15.04 destroy
[07:52] <zbenjamin> dpm: to create new ones on cli just replace destroy with create. Then your QtC is not blocked and you can at least use the desktop kit
[07:52] <dpm> ok, will try that, thanks!
[07:52] <zbenjamin> dpm: but restart it after destroying but before starting the creation of new ones
[07:52] <dpm> ok
[07:53] <zbenjamin> dpm: i wonder what broke it so badly. Never saw that before oO
[07:54] <dpm> zbenjamin, argh: http://paste.ubuntu.com/16060528
[07:54] <dpm> not my day today
[07:54] <zbenjamin> dpm: noooo , how much i hate that error
[07:55] <zbenjamin> dpm: you could try to reboot
[07:56] <zbenjamin> dpm: there are more brutal measures but i'd prefer if your homedir is safely unmounted
[07:56] <dpm> ok
[08:06] <dpm> zbenjamin, ok, I could destroy the kits now. Also, something I've meant to ask for a while: why are there 2 entries in the Dash for the IDE? "Ubuntu SDK" and "Ubuntu SDK IDE", is this a known bug, and does it make a difference which one I choose?
[08:16] <dpm> zbenjamin, it seems they are different -> http://paste.ubuntu.com/16060604
[08:16] <zbenjamin> dpm: right you do not need the one from archive "apt-get remote qtcreator"
[08:16] <zbenjamin> s/remote/remove
[08:16] <dpm> aha
[08:17] <zbenjamin> dpm: apt refused to uninstall the other one automatically.. bzoltan_ knows more about that problem
[08:17] <dpm> zbenjamin, wait, but that extra .desktop file comes from qtcreator-plugin-ubuntu, not qtcreator
[08:18] <zbenjamin> dpm: right, it should be removed together with qtcreator
[08:18] <zbenjamin> dpm: you want "ubuntu-sdk-ide" which is the one from the ppa
[08:19] <dpm> zbenjamin, hm. Removing either 'qtcreator' or 'qtcreator-plugin-ubuntu' wants to remove 'ubuntu-sdk'
[08:20] <dpm> Also, the version of 'ubuntu-sdk' in the PPA is older than the one in the archive
[08:21] <dpm> I'm utterly confused now
[08:23] <zbenjamin> bzoltan_: ^^^^^
[08:23] <zbenjamin> bzoltan_: we need to bump the ubuntu-sdk version in the ppa
[08:24] <zbenjamin> bzoltan_: and we should remove the qtcreator and plugins from the archive version. It constantly breaks
[08:25] <bzoltan_> dpm: apt-cache policy ubuntu-sdk
[08:25] <zbenjamin> dpm: it does not harm if its installed. But you are right thats too confusing .... maybe we should remove the IDE from the ubuntu-sdk metapackage and let people install ubuntu-sdk and ubuntu-sdk-ide seperately
[08:26] <zbenjamin> or let ubuntu-sdk-ide pull ubuntu-sdk
[08:26] <zbenjamin> bbl, need to let the dog out
[08:27] <dpm> bzoltan_, well, that's actually what I ran to find out that the PPA version is older than the archive http://paste.ubuntu.com/16060651
[08:27] <dpm> zbenjamin, it's not just the fact that they are confusing, they do execute two different instances of qt creator
[08:28] <zbenjamin> dpm: you are right thats really bad.
[08:28] <dpm> and presumably you only want to track one
[08:28] <bzoltan_> dpm: somebody keeps pushing updates to the seeds without paying much attention to the effect :(
[08:28] <bzoltan_> dpm: obviously the seeds need to be fixed
[08:28] <zbenjamin> bzoltan_: can we reverse the dependencies?   Instead of ubuntu-sdk pulling the IDE, we do it the other way round and tell ppl to install ubuntu-sdk-ide
[08:29] <zbenjamin> bzoltan_: and remove the IDE from the ubuntu-sdk metapackage everywhere
[08:29] <zbenjamin> bzoltan_: that would solve it for good and we do not need to have our own metapackage in the ppa
[08:29] <dpm> zbenjamin, bzoltan_, where is the best place to report this as a bug to track it?
[08:29] <bzoltan_> dpm: seed package
[08:30] <bzoltan_> dpm: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.xenial/files
[08:30] <bzoltan_> dpm: I can fix the PPA version like zillion times if people keep pusing this http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.xenial/view/head:/sdk
[08:31] <dpm> bzoltan_, I guess that'd be for the seeds themselves. But that won't fix the fact that qtcreator ships the .desktop file that's got the same icon but executes a different binary
[08:32] <bzoltan_> dpm: we can change the icon and the desktop file of course
[08:32] <bzoltan_> dpm:  in Y
[08:32] <bzoltan_> dpm:  of SRU in X
[08:32] <bzoltan_> of - or
[08:34] <dpm> bzoltan_, ok, if I report this against the seeds package, given that seeds version < PPA version... what should be the solution? I don't think the seeds version can be downgraded
[08:35] <dpm> is it not just a matter of a) updating the version in the PPA and b) improving communication?
[08:35] <bzoltan_> dpm:  seed version should not be downgraded... it simple should remove all the qtc* packages from its list
[08:42] <dpm> bzoltan_, zbenjamin, ok, filed https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1575048 - could you guys please comment in the bug? I don't think it should be me driving this, as I'm far from an expert
[08:42] <dpm> bzoltan_, zbenjamin, for the more immediate issue of removing qtcreator, what steps would you recommend?
[08:43] <dpm> (as sudo apt remove qtcreator wants to remove ubuntu-sdk)
[08:54] <bzoltan_> dpm:  I have pushed a winning update to the PPA
[08:55] <dpm> awesome
[09:04] <dpm> bzoltan_, zbenjamin, ok, reported bug 1575062 for the icons issue
[09:05] <dpm> bzoltan_, so last question, once apt sees the update in the PPA, what will be the steps necessary to remove qtcreator? 'sudo apt remove qtcreator', or 'sudo apt remove qtcreator-plugin-ubuntu', or something else?
[09:07] <bzoltan_> dpm:  removing the qtcreator-plugin-ubuntu should do the trick
[09:09] <dpm> bzoltan_, ok, great, thanks! I'll try 'apt update' again in a bit and give it a go
[09:11] <zbenjamin> dpm: apt-get remove qtcreator, except for some reason you want to keep the archive qtc
[09:11] <dpm> you guys are telling me different things to do :)
[09:24] <timp> zbenjamin: I also have qtcreator from the archive installed
[09:25] <timp> is there a new tutorial on how to get the ppa qtc?
[09:26] <zbenjamin> timp: add the ppa and install ubuntu-sdk-ide.  Then remove the other one "apt-get remove qtcreator qtcreator-plugin-ubuntu"
[09:26] <timp> I have the ppa
[09:26] <zbenjamin> timp: https://developer.ubuntu.com/en/blog/2015/11/19/here-comes-brand-new-ubuntu-sdk-ide-tools/
[09:26] <timp> I don't know why I have qtc from the archive
[09:27] <zbenjamin> timp: most likely because the ubuntu-sdk package was overruled by the archive one, which pulled the one from the archive
[09:28] <timp> could be
[09:32] <timp> zbenjamin: the blog post mentions 'apt distupgrade'. Is that 'apt full-upgrade' now?
[09:32] <timp> ah dist-upgrade still works too
[09:34] <zbenjamin> timp: could be that it was changed ...
[09:43] <timp> kalikiana: so, on https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/sections-keyboard/+merge/292587 I added a FIXME in a comment
[09:44] <timp> kalikiana: I think it is a separate issue, needs to be fixed in the APL but I don't know how much work that will be
[13:17] <nik90> nik90_mobile, ping
[13:17] <nik90_mobile> nik90, hello there
[13:17] <davmor2> oh god nik90 has been at the cloning machine again
[13:18] <nik90_mobile> Loop woo chatter is awesome
[13:18] <nik90_mobile> Lol
[13:30] <oresama> .
[13:32] <nik90> dpm, mhall119: Do you know where the snappy clinic today is being held? Is it on ubuntu-on-air?
[13:33] <dpm> nik90, we decided to move it to next week's UOS (sorry for the inconvenience :/)
[13:34] <nik90> dpm, oh nvr mind, I was just about to make an announcement on the ubuntu-app-dev telegram channel..good think I asked ;)
[13:34] <dpm> there are a couple of snappy things that need fixing, and we figured out it'd make more sense to wait until UOS and we'd have more audience too
[13:35] <nik90> hmm, makes sense
[15:20] <timp> mardy: hello
[15:20] <timp> I was just reading your latest comment on https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1572525
[15:20] <timp> I commented back
[15:21] <timp> perhaps we can discuss it together in a meeting with designers?
[15:55] <mardy> timp: I don't think that a meeting with the designers is necessary, and I can certainly live with the fixed header; it's more a matter of principle, but I don't intend to have a fight over it :-)
[15:56] <mardy> timp: let me just write the same as a comment on the bug
[15:56] <timp> mardy: okay, thanks
[15:57] <timp> mardy: probably for UITK2 the header is not going to change any properties of the flickable
[15:57] <mardy> timp: that's the best thing indeed
[15:57] <timp> mardy: so the app developer will have to do all that. The automatic behavior that we have now is a leftover from the previous header where you didn't have access to its height and you could not anchor to it from the app.
[15:57] <timp> but changing that now would require all apps to be changed
[16:05] <timp> mardy: I will close the bug then. Sorry, I know it is not completely satisfactory for you and if I had infinite time I would spend more of it on this bug.
[16:05] <timp> mardy: but when we start to work on the UITK2 APIs, we will announce it and ask people for input
[16:06] <mardy> timp: ok, no hard feelings :-)
[16:33] <kisb> hello
[16:37] <kisb> anyone there???
[16:37] <kisb> we have questions
[19:45] <Tim> Wohoo!! Sent via Chatter
[19:46] <Tim> Awesome! :)
[19:46] <subet> https://uappexplorer.com/app/chatter.robert-ancell
[19:47] <subet> ^ really nice
[22:13] <m_jimmer> Does anyone know how can I use ListModel to append with a var ?  example  http://pastebin.com/gf3YpQR0 its the role name that is getting in the way. Seems like one can not use anything but strings ?
[22:14] <m_jimmer> it is line ten that is the issue


[00:12] <Debolaz> If I want to set aside a few hours each week contributing to Ubuntu, which areas are in the most need of help? I know most technical things to an acceptable level and don't mind learning.
[00:17] <alazare619> http://pastebin.com/2LLw1PuE
[02:41] <bretth> is libwebkitgtk-3.0.so on Ubuntu12.04 not built with wegGL support?
[03:27] <alazare619> how do you call a chroot-hack from livecd-rootfs scripts?
[03:29] <micahg> bretth: no, it's not
[03:32] <bretth> micahg, too bad, it would be better to have webgl by default.
[08:43] <Cleitus> i'm a guy with interest in programming and love to develop for linux or android platforms can anyone give me suggestions
[09:27] <DktrKranz> infinity: re your r-base_2.15.1-1ubuntu1 upload, do you know whether the POSIX estended breakage on ARM is tracked somewhere (bug reports, mailing lists, whatever) ?
[10:17] <cousteau> fact 1:  Flash is going to stop being supported for Linux
[10:17] <cousteau> fact 2:  the only way to use newer Flash versions on Linux will be using Chrome
[10:18] <cousteau> fact 3:  Firefox is the default browser in Ubuntu (and even if it weren't, the user should be able to use whatever browser they want, not a specific one only because of this sort of things)
[10:19] <cousteau> fact 4:  my own experience tells me that Flash runs better on Wine than natively (at least older versions; not sure now)
[10:20] <cousteau> idea:  would it be possible to develop a Wine-based wrapper for Adobe Flash (and maybe Shockwave)?  This would not only provide an alternative for those who want to use Flash but also work better than the native one.
[10:21] <cousteau> (as far as I know Google does this sort of things with Google Earth and similar)
[10:30] <infinity> DktrKranz: I haven't filed bugs yet, I was planning to work on it at some point.  But maybe I should just file a Debian bug when I get home, so I don't forget.
[10:57] <ramona> does any one have any problems with javaws in ubuntu 12? Java applets runs terribly slow on my machine
[10:58] <ramona> they run fine in windows
[10:59] <cousteau> maybe because of openjdk/oracle differences
[11:00] <ramona> cousteau, I tried both openjdk and oracle
[11:01] <cousteau> maybe video card or graphic acceleration issues?  (no idea what else could be...  then again I'm no expert)
[11:02] <ramona> cousteau, It used to run fine on 10.04
[11:45] <bencer> quick question, i'm preparing a SRU, LP doesn't allow me to upload a package with target precise-proposed, how should i proceed with that?
[11:46] <Laney> in what way does it not allow this?
[11:46] <bencer> Laney: LP rejects the target
[11:47] <bencer> Laney: when uploading to my PPA
[11:47] <Laney> not sure proposed exists for PPAs
[11:49] <bencer> Laney: should i upload with precise target and thats it?
[11:50] <Laney> bencer: yeah. if you need extra build-dependencies from proposed then you can configure the ppa to give those
[11:51] <bencer> not really, okey
[11:51] <bencer> thx
[21:49] <bdrung> infinity: yes. eat your own dogfood! ;)
[21:49] <bdrung> infinity: you can backport the latest devscripts version and still get an unchange default distribution.