=== Lutin is now known as Guest9763
=== sebner_ is now known as sebner
=== Zhenech_ is now known as Zhenech
=== warren is now known as Guest5078
=== Guest5078 is now known as djwattz
[01:21] <djwattz> '
[05:07] <kaushal> hi
[05:08] <kaushal> is http://dev.mysql.com/downloads/workbench/#downloads available in Ubuntu repository ?
[05:11] <Bachstelze> kaushal: doesn't look like it
[05:11] <kaushal> ok
[05:12] <kaushal> Bachstelze: Any specific reason why its not available in the repository ?
[05:14] <micahg> kaushal: no one has had time to package it yet is the most likely reason
[05:15] <kaushal> micahg: ok
[05:17] <micahg> debian 584987 was filed to replace mysql-gui-tools with it
[05:17] <ubottu> Debian bug 584987 in mysql-gui-tools "mysql-gui-tools: EOL upstream, should not be shipped in squeeze, replaced by MySQL Workbench" [Important,Open] http://bugs.debian.org/584987
[05:20] <kaushal> micahg: ok
[05:21] <kaushal> micahg: is it related to Ubuntu ?
[05:21] <kaushal> since it mentions about debian
[05:21] <kaushal> I know Ubuntu is from Debian SID
[05:23] <micahg> kaushal: we get over 75% of our packages from Debian
[05:23] <kaushal> oh ok
[05:24] <kaushal> micahg: Are there any documents which mentions about this ?
[05:24] <micahg> kaushal: we're spread pretty thin, so we usually wait for new packages to get in through Debian unless a specific Ubuntu Developer has an interest in the packagte
[05:25] <micahg> kaushal: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[05:28] <micahg> hi bilalakhtar, thanks for the accolades
[05:29] <bilalakhtar> micahg: no problem, I already had to update the topic, and add the fact that maverick-proposed is open. Just before /topic-ing, I noticed that the end of the topic says: Congrats to new MOTU: debfx . Just changed it to your nick
[05:30] <bilalakhtar> bdrung: Thanks for that gimp upload!
[05:31] <bilalakhtar> bdrung: Dunno why it was being ignored till now, since it was a work item for me, assigned at UDS
[05:31] <kaushal> micahg: Thanks again for the explanation
[05:31] <kaushal> much appreciated
[05:31] <micahg> kaushal: no problem
[05:38] <kaushal> micahg: I did apt-cache search mysql |grep -- ^mysql-
[05:39] <kaushal> what does -- signifies mean after grep command ?
[05:39]  * micahg isn't suer
[05:39] <micahg> *sure
[05:39] <ebroder> It means that all arguments after it are treated as filenames to search
[05:41] <kaushal> ebroder: ok
[05:41] <kaushal> thanks
[05:41] <kaushal> so if i just do grep ^mysql- ?
[05:42] <ebroder> That would print out all lines that start with mysql, yes
[05:43] <kaushal> so there is no difference
[05:43] <kaushal> ?
[05:43] <kaushal> not sure i understand that
[05:53] <kaushal> ebroder: you around ?
[06:00] <Bachstelze> kaushal: what are you trying to do?
[06:00] <kaushal> Bachstelze: np
[06:00] <kaushal> i got it now
[06:01] <kaushal> just trying to understand the difference between grep -- ^mysql- and grep ^mysql-
[06:01] <kaushal> curious to knpw
[06:01] <kaushal> know*
[06:27] <ebroder> kaushal: Sorry, stepped away for a bit
[06:28] <ebroder> I'm not sure what I said before was right. Normally, if you have a command that takes both options (i.e. -r or -l) and arguments, you can use -- to separate the options and the arguments
[06:29] <ebroder> "ls -l" means do a long listing. "ls -- -l" means list the file or directory -l
[06:29] <ebroder> I don't know exactly how -- works with grep, though
[06:40] <StevenK> -- is shorthand for 'anything after it isn't an option'
[08:08] <dholbach> good morning!
[08:10] <stefanlsd> morning!
[08:11] <stefanlsd> ebroder: fixed that dkms issue i was having. dkms error reporting isnt great
[08:14] <stefanlsd> What happens to the changelog when doing a UDD merge?  seems like its ignored?
[08:26] <geser> what you mean with "ignored"?
=== hanska is now known as dapal
[10:57] <ari-tczew> I heard that everybody in ~ubuntu-dev can ACK sync of a new package. is it true?
[11:13] <tumbleweed> ari-tczew: the archive admins process new package syncs periodically, but if it's urgent yes, any MOTU can ack a sync destined for universe/multiverse
[11:14] <ari-tczew> tumbleweed: but not every ~ubuntu-dev member is MOTU.
[11:14] <AnAnt> Hello
[11:14] <ari-tczew> like kklimonda
[11:14] <ari-tczew> hello AnAnt
[11:14] <tumbleweed> ari-tczew: you can only ack for things you can upload to
[11:14] <tumbleweed> an ack is a sign that you've done all the checks you would do if you were sponsoring the upload, you just haven't uploaded
[11:15] <ari-tczew> very odd
[11:15] <ari-tczew> tumbleweed: look on bug 673230
[11:15] <ubottu> Launchpad bug 673230 in ubuntu-sponsoring "Privilegles status doesn't show correctly" [Undecided,Incomplete] https://launchpad.net/bugs/673230
[11:19] <tumbleweed> ari-tczew: no idea, AFAIK new packages come into universe, so MOTUs can ack new packages, not sure about how this relates to ~ubuntu-dev
[11:32] <geser> ubuntu-dev = core-dev + motu + packageset uploaders + ppu
[11:33] <ari-tczew> geser: ok, what's the conclusion?
[11:34] <geser> not sure yet, have to think about it
[11:35] <ari-tczew> ok
[11:35] <geser> have you a link to documentation which tells who can ACK a sync?
[11:49] <Laney> so MOTU can upload NEW packages
[11:49] <Laney> therefore can ack their sync
[11:49] <geser> ari-tczew: it probably should work like this: motu+core-dev can ACK new package syncs, package set uploaders can ACK new package syncs that belong to their package set (not yet but will once they are in the archive and added to the package set), PPU can't ACK new package syncs as we don't give PPU for packages not yet in the archive
[11:49] <geser> I hope I didn't miss a valid case
[11:49] <Laney> for other packages  I have bene informed that once there is a SPPR (or whatever) for it anywhere in LP then they can be added to a set
[11:49] <Laney> so you can upload to $PPA and have it added to your set and then sync
[11:49] <Laney> or probably just do this informally through AAs, I doubt there would be a problem
[11:50] <dholbach> ari-tczew, the code in the sponsoring overview uses code that is very very similar to http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head:/sync-helper.py#L67
[11:50] <dholbach> so what the archive admins use
[11:50] <Laney> speaking of sets, ...
[11:50] <Laney> cjwatson: could you add dbus-sharp dbus-sharp-glib to cli-mono please?
[11:51] <geser> Laney: is the cli-mono package set TB or DMB managed? if it's the later any DMB member can do it
[11:52] <Laney> oh, don't know
[11:53] <Laney> I've only ever pinged cjw before, let's see
[11:53] <Laney> dmb owns the team... how do you find out for the set? want to just try?
[11:53] <geser> Laney: that always works as Colin is both TB and DMB
[11:54] <geser> Laney: I could try but as I'm currently at work, I don't have access to my computer where I've set up everything
[11:55] <Laney> ok
[11:56] <geser> Laney: grab your package set through the LP API and look at the owner attribute
[12:01] <Laney> >>> set.owner.display_name
[12:01] <Laney> 'Ubuntu Technical Board'
[12:01] <Laney> geser: ^^^
[12:02] <geser> then you need someone from TB to get those package added
[12:02] <Laney> ok, already done ;)
[12:02] <Laney> I wonder if it should not be DMB though… was the first packageset of this kind so kind of broke new ground
[12:03] <dholbach> https://wiki.ubuntu.com/ArchiveReorganisation/Permissions#Technical Board considerations
[12:04] <geser> I know that the "mozilla" and "zope" package set are DMB owned, all other package set TB owned
[12:04] <dholbach> oh... I thought all were TB-owned
[12:04] <dholbach> hmhm
[12:07] <geser> I don't remember how it came that DMB created the "mozilla" package set; have to check the meetings logs for it
=== yofel_ is now known as yofel
[12:31] <cjwatson> Laney: done
[12:32] <Laney> thanks a lot
[12:32] <cjwatson> I'd be OK with the cli-mono set becoming DMB-owned, probably ought to be signed off by other TB folks though
[15:24] <ScottK> barry: I'd appreciate it if you would have a look at the proposed patch in https://bugs.launchpad.net/bugs/674009 and give an opinion on it.
[15:24] <ubottu> Launchpad bug 674009 in pyme (Ubuntu) "in pyme.core.Data fail new_from_fd function" [Undecided,New]
[16:26] <AnAnt> Hello, is this build failure Natty-specific: http://launchpadlibrarian.net/58996466/buildlog_ubuntu-natty-i386.python-whoosh_1.2.6-1_FAILEDTOBUILD.txt.gz ? I don't get this build error under Maverick
[16:27] <AnAnt> in other words, is it actually a problem in python-whoosh or python2.7 in Ubuntu ?
[16:31] <Rhonda> Why did helloubuntu.com end on november 6th?
[17:18] <geser> AnAnt: could be the same issue as bug 671441
[17:18] <ubottu> Launchpad bug 671441 in joblib (Ubuntu) "joblib FTBFS in Natty" [Medium,Confirmed] https://launchpad.net/bugs/671441
[17:19] <AnAnt> geser: how's that
[17:19] <AnAnt> ?
[17:21] <AnAnt> geser: I get this FTBFS on maverick too btw with python-whoosh, but I added patch to workaround this  issue
[17:21] <AnAnt> geser: actually, it is that patch that causes python-whoosh to FTBFS on natty
[17:23] <geser> AnAnt: the bug is about /dev/shm not being mount in the buildds which make the test fail as it tries to create a semaphore (which IIRC is stored in /dev/shm)
[17:23] <geser> and when you compare in which module the both tests fail, you notice the same python module (multiprocessing)
[17:24] <AnAnt> geser: here's the patch that is causing the FTBFS: http://svn.debian.org/viewsvn/python-modules/packages/python-whoosh/trunk/debian/patches/shm_check.diff
[17:25] <AnAnt> but that does not happen in maverick
[17:31] <geser> AnAnt: looks like the exception changed. The patch catches OSError (like the error in the bug I mentioned) while your build log shows an ImportError
[17:32] <geser> try modifying the patch to "except (OSError, ImportError):"
[17:32] <AnAnt> geser: yup, the Queue() call causes the ImportError
[17:33] <AnAnt> geser: modifying the patch will fix it , but my question is: is the problem actually in whoosh or python2.7 ?
[17:33] <geser> AIUI neither, but a problem on the buildds
[17:35] <AnAnt> AIUI ?
[17:37] <geser> As I Understand It
[17:38] <ari-tczew> stefanlsd: you don't need to mention in d/changelog: - debian/control: Change Maintainer
[17:40] <AnAnt> geser: ok
[17:56] <ari-tczew> wow! new wiki style!
=== hannesw_ is now known as hannesw
=== bcurtiswx__ is now known as bcurtiswx_
[18:06] <achiang> if i'm developing a small package in my own ppa, what is the proper method to ensure it is installable in both maverick and lucid? what keys off the distro series in debian/changelog? just the PPA buildd?
[18:07] <achiang> iow, if my distro series is maverick, the buildd will build it in a maverick chroot; but will lucid users subscribed to my ppa still be able to install the package?
[18:07] <ari-tczew> achiang: normal set release - lucid or maverick. in versioning you can use ~ppa0
[18:07] <ari-tczew> achiang: or ~lucid1 ~maverick1~
[18:08] <micahg> achiang: no, each series is a separate repo
[18:08] <micahg> s/is/has/
[18:09] <micahg> achiang: so you can either build on lucid and copy forward, or upload to both lucid and maverick with slightly different versions as ari-tczew suggests
[18:09] <achiang> micahg: hm. so that means on my actual hard drive, i need to have 2 parallel directories with essentially the same source, but two different debian/changelogs ; the only difference being the distro series?
[18:09] <achiang> oh... hm.  a binary copy to a maverick ppa
[18:10] <micahg> achiang: can be the same PPA, just different series (BTW, #ubuntu-packaging is more appropriate for this)
[18:10] <ari-tczew> no need separate PPA for another release
[18:12]  * achiang hops over to #ubuntu-packaging
=== makl is now known as ximion
[18:16] <psusi> it seems to me that one should use +ppa0 rather than ~ppa0, because foo2~ppa0 will be treated as > foo1.2
[18:17] <micahg> psusi: well, depends on what version is there, I prefer verion~series~ppaX
[18:17] <micahg> *version
[18:17] <micahg> psusi: that way it won't conflict with official backports
[18:18] <psusi> micahg: yea, but if there is then an official version.2 released, it won't superceed your version~
[18:18] <micahg> psusi: well, you wouldn't want it to in most cases
[18:18] <micahg> as it would be a different branch
[18:18] <psusi> why not?  it is newer than yours
[18:19] <micahg> psusi: oh, I see like ubuntu2 vs ubuntu 1.2
[18:19] <psusi> if you take version1 and patch it, and call it version2~ppa0, then upstream comes out with version1.1, it won't replace yours
[18:19] <micahg> psusi: so in that case yes, you would want the +ppa, but in a lot of cases, the PPA versions are ahead of what's currently in teh archive
[18:19] <psusi> exactly
[18:57] <ari-tczew> Rhonda: around?
[19:07] <Rhonda> ari-tczew: It would be useful if you could add content to your ping, then I could respond with something fruitful, too. :)
[19:07] <ari-tczew> Rhonda: I'm pleased to see that your changes in packages.ubuntu.com have been applied.
[19:08] <Rhonda> You already mentioned that.
[19:08] <Rhonda> And actually I applied them myself.
[19:09] <ari-tczew> Rhonda: did you got upload access?
[19:09] <Rhonda> Rather shell access. Wouldn't work with "upload"
[19:10] <ari-tczew> Rhonda: you know what I mean. we had discussion last time about it.
[19:11] <Rhonda> Yes, and I told you back then that it's in the works and that I have it on my agenda.
[19:16] <ari-tczew> Rhonda: summarizing - did you got what you want or no?
[19:16] <stefanlsd> ari-tczew: yeah thanks. was just a previous change, so i left it
[19:17] <Rhonda> Was my response really that unclear? Yes, I have shell access. Yes, I am able to apply the changes myself.
[19:19] <cody-somerville> so whats the correct way to run autoreconf in lucid with a package using dh7 since dh-autoreconf doesn't exist in lucid?
[19:28] <ScottK> congratulations then Rhonda.  That's one roadblock to progress sovled.
[19:29] <sebner> anyone already using natty? Will it explode if I upgrade? =)
[19:31]  * Rhonda . o O ( No, I haven't changed the admin contact address yet. Actually thinking of changing it to a list. )
[19:31] <Rhonda> ScottK: Thanks. :)
[19:31] <Rhonda> And thanks to cjwatson for directing me properly. :)
[19:32] <micahg> Rhonda: +1 for a team/list, is it worth a project on launchpad?
[19:33] <Rhonda> micahg: Not certain. The code is in git.debian.org. :)
[19:34] <Rhonda> Actually I think of moving the code to git.deb.at where I can use gitolite ACLs.
[19:41] <ari-tczew> Rhonda: my internet fail again. could you pastebin last lines from this channel? irclogs is not updated (I know, it's a few minutes)
[19:46] <Rhonda> What was the last message you saw?
[19:48] <ari-tczew> Rhonda: <Rhonda> Yes, and I told you back then that it's in the works and that I have it on my agenda.
[19:49] <ari-tczew> Rhonda: I'm really pleased when during discussion I'm pinged. Then I couldn't forget about discussion. :)
[19:49] <Rhonda> <Rhonda> Was my response really that unclear? Yes, I have shell access. Yes, I am able to apply the changes myself.
[19:50] <ari-tczew> Rhonda: only this one? ok, my phrase then:
[19:50] <ari-tczew> Rhonda: summarizing - did you got what you want or no?
[19:50] <Rhonda> That was my response that specific question. :)
[20:01] <xteejx> Can I request a giveback on bzr in main? It builds fine locally, build-deps seem ok now
[20:04] <xteejx> and bzrtools
[20:04] <ajmitch> xteejx: is python-testtools in main now?
[20:04] <xteejx> ajmitch: Yes, I believe so, pbuilder picked it up
[20:05] <ajmitch> & you didn't have universe enabled?
[20:05] <ajmitch> since LP still reports it as being in universe
[20:05] <xteejx> ajmitch: Not afaik :S
[20:06] <xteejx> Hmm, perhaps it *is* enabled
[20:06]  * ajmitch suspects that you may have had it enabled, python-testtools will need to be promoted to main if it's needed to build packages in main
[20:06] <xteejx> Ignore me :P
[20:07] <xteejx> Sorry about that
[20:09] <ajmitch> not a problem :)
[20:09] <xteejx> :)
[20:09]  * ajmitch suspects it won't be hard to get into main, given who's upstream for it
[20:09] <xteejx> one of our guys I assume?
[20:10] <ajmitch> yeah
[20:30] <ari-tczew> ld: cannot find -lQtCore
[20:30] <ari-tczew> which Build-Depends is missing?
[20:31] <ari-tczew> xteejx: if locally package built fine but build-machine has FTBFS, perhaps pbuilder is not good. try build by sbuild
[20:32] <xteejx> ari-tczew: python-qt4-dev ?
[20:32] <Rhonda> ari-tczew: apt-file libQtCore
[20:33] <xteejx> or libqt4-dev
[20:33] <xteejx> ari-tczew: It's ok, I've sorted out the pbuilder problem :)
[20:34] <Rhonda> ari-tczew: For questions like this I usually keep a copy of the Contents file locally to zgrep on.
[20:34] <Rhonda> apt-file can help with that, there are other approaches, too.
[20:35] <Rhonda> Another approach is: http:/packages.ubuntu.com/ and inser libQtCore.so in the content search form.
[20:35] <Rhonda> insert*
[20:35] <Rhonda> That way you can answer this question yourself next time. ;)
[20:37] <ari-tczew> Rhonda: try this command locally. doesn't work :P
[20:38] <ari-tczew> it gives --help
[20:38] <Rhonda> Then read it? :)
[20:38] <micahg> ari-tczew: apt-file search libQtCore
[20:38] <Rhonda> Like said, I have a copy of the Contents file locally, so I'm not too familiar with the apt-file handling. I just know that it can answer the question that you had for you.
[20:39] <Rhonda> And it has a manual page, too. IRC shouldn't be your replacement to reading documentation, you know. ;)
[20:39] <ari-tczew> thanks micahg
[20:39] <ari-tczew> xteejx: you're right, libqt4-dev
[20:39] <xteejx> woohoo :D
[20:39] <ari-tczew> but it's already in Build-Depends :/
[20:39] <ari-tczew> what's wrong?
[20:41] <xteejx> could it be that -I/usr/lib needs to be added to the compile line?
[20:42] <ari-tczew> xteejx: I added LDFLAGS to d/rules
[20:43] <xteejx> ari-tczew: Just a guess, but you might need to edit or patch the actual source
[20:43] <Rhonda> I don't think so
[20:43] <xteejx> I'm just guessing :) Hard to know without seeing the source
[20:45] <Rhonda> There should be a config.log or something that contains more information on the error.
[20:49] <ScottK> ari-tczew: What package?
[20:50] <ari-tczew> ScottK: xca
[20:52] <ari-tczew> xteejx: could you try to fix FTBFS on xca from Debian unstable?
[20:52] <xteejx> I'm doing something else
[20:52] <ari-tczew> package is sync ready, but one remaining changes is LDFLAGS to workaround FTBFS.
[20:54] <ScottK> ari-tczew: How did you add -lQtCore?
[20:54] <ari-tczew> ScottK: LDFLAGS = -Bsymbolic-functions -lQtCore (debian/rules)
[20:58] <ScottK> ari-tczew: Try -lQtCore4.
[21:00] <Rhonda> ScottK: There is no libQtCore4.so?
[21:01] <xteejx> apt-file has nothing for that
[21:01] <ari-tczew> ScottK: ld: cannot find -lQtCore4
[21:01] <ScottK> Not sure then
[21:02] <ari-tczew> marking as FTBFS on MoM
[21:10] <ScottK> ari-tczew: I bet the current Ubuntu package is also FTBFS.
[21:11] <ari-tczew> ScottK: I can check.
[21:11] <xteejx> How do I find out what to link for an undefined reference?
[21:11] <xteejx> I tried apt-file search, but nothing came up
[21:12] <ari-tczew> maybe it's looking on package which is not exist in archive
[21:18] <ari-tczew> ScottK: current xca in Ubuntu - /usr/lib/libQtCore.so.4: could not read symbols: Invalid operation
[21:19] <ScottK> So there's a problem either way.
[22:20] <ScottK> JFTR, adding -lstdc++ and -lQtCore to LIBS fixes the FTBFS.  Didn't have time to sort out the best place to attach it.
=== ivoks is now known as ivoks-afk
=== maxb_ is now known as maxb
=== Philip6 is now known as Philip5