=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[07:09] <dholbach> good morning
=== Whoopie_ is now known as Whoopie
=== jalcine_ is now known as Guest2983
=== almaisan-away is now known as al-maisan
[09:25] <Whoopie> Hi, is one aof the MOTU devs available to sponsor a package? Please have a look at bugreport 913018.
[09:25] <Whoopie> The package was approved by ScottK.
[09:25] <Whoopie> https://bugs.launchpad.net/ubuntu/+source/sflphone/+bug/913018
[09:25] <ubottu> Launchpad bug 913018 in sflphone (Ubuntu) "sflphoned crashed with SIGSEGV in std::__detail::_List_node_base::_M_hook() from DBus::DefaultWatch::DefaultWatch" [Medium,New]
[09:28] <tumbleweed> Whoopie: it's in the sponsorship queue. You don't need to ask, unless you're in a particular hurry
[09:29] <Whoopie> tumbleweed: ok, thanks.
[09:30] <tumbleweed> np. You can see the queue here: http://reqorts.qa.ubuntu.com/reports/sponsoring/
=== al-maisan is now known as almaisan-away
=== Guest37736 is now known as Zic
[10:41] <adhorden> Hi, what is the best way to create a new user and group inside a new package? There seems to be a few methods.
[10:43] <vibhav> Should I request a sync or prepare a patch for https://bugs.launchpad.net/ubuntu/+source/jinput/+bug/951533?
[10:43] <ubottu> Launchpad bug 951533 in jinput (Ubuntu) "libjinput-jni: contains undefined symbol EVIOCGUSAGE" [Undecided,New]
[10:47] <tumbleweed> adhorden: basically, adduser --system, with a username that's almost certain to be unique on every system this package gets installed on
[10:47] <adhorden> tumbleweed: add that to my postinst? I could not find any examples
[10:47] <geser> vibhav: sync; as the new Debian upload is only that patch, it doesn't make sense to upload the same patch directly to Ubuntu and create an Ubuntu delta (which isn't a delta anyway)
[10:48] <tumbleweed> adhorden: yes. And if you have any files that need to be owned by that user, change the ownership with dpkg-statoverride
[10:49] <geser> adhorden: check the system users on your system and see how those packages done it
[10:50] <adhorden> tumbleweed, geser thanks, the mongodb package looks a good one for examples
[10:51] <tumbleweed> yes, that looks reasonable
[11:00] <ryanakca> Could someone with access to a precise box please test the no changes rebuild of 'python-poppler-qt4' from ppa:ryanakca/frescobaldi and see if it fixes bug 939196 ?
[11:00] <ubottu> Launchpad bug 939196 in frescobaldi (Ubuntu) "frescobaldi crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed] https://launchpad.net/bugs/939196
=== genupulas is now known as ubucop
=== almaisan-away is now known as al-maisan
[12:21] <adhorden> I have successfully added a user and group, but I keep getting dpkg-statoverride: error: syntax error: unknown group 'admin' in statoverride file, I have not set a group admin any where, why would I get this?
=== yofel_ is now known as yofel
[13:50] <brainstorm> hello MOTUs
[13:50] <brainstorm> can anyone help me with a strange PPA reject (package removed but still complaining about remote .orig.tbz2 file ?): https://lists.launchpad.net/launchpad-users/msg06416.html
[13:52] <tumbleweed> brainstorm: LP remembers published .orig. files forever
[13:52] <brainstorm> wow
[13:53] <brainstorm> so I screwed badly by removing it from the PPA, right ? :_/
[13:53] <brainstorm> how should I proceed ?
[13:53] <tumbleweed> https://answers.launchpad.net/launchpad/+faq/990
[13:54] <brainstorm> humm, thanks !
[13:55] <brainstorm> I bumped via dch -i but I guess it's not enough, the .orig file requires a bump as well
[13:55] <tumbleweed> or just don't change it
[13:55] <brainstorm> :-?
[13:56] <tumbleweed> the problem was that you changed the content sof the file
[13:56] <tumbleweed> you shouldn't be doing that
[13:56] <brainstorm> well, the "rules" file fetches it from SVN upstream, so files are bound to change eventually :-/
[13:57] <tumbleweed> then your version should include the svn revision
[13:57] <tumbleweed> e.g. 1.2.3+svn419-1
[13:58] <brainstorm> humm, ok, thx for that !
=== vibhav is now known as vibhavp
=== al-maisan is now known as almaisan-away
[14:42] <brainstorm> tumbleweed: tried with "picard-tools_1.64.orig-ubuntu1.tar.bz2" but it expects one of "picard-tools_1.64.orig.tar.gz, picard-tools_1.64.orig.tar.bz2,
[14:42] <brainstorm> picard-tools_1.64.orig.tar.lzma,  picard-tools_1.64.orig.tar.xz or picard-tools-1.64.orig" :-/ Any way to override/define this ?
[14:44] <tumbleweed> brainstorm: that dosen't contain a SVN revision either
[14:44] <brainstorm> yep because it's checked out from tags
[14:44] <brainstorm> so I figured out to keep it this way, but extend it with a static string, until next release comes up
[14:44] <tumbleweed> ok, the upstream version number should be 1.64 then
[14:45] <tumbleweed> so, 1.64-0ubuntu1 or something like that
[14:45] <brainstorm> aha
[14:45] <tumbleweed> meaning picard-tools_1.65.orig.tar.bz2
[14:46] <brainstorm> well, I cannot bump the orig to 1.65 since it has not came out yet
[14:47] <brainstorm> but I'll try with 1.64-0ubuntu1.orig.tar.bz2
[14:51] <tumbleweed> but it's been tagged?
[14:51] <tumbleweed> you tag things before they are released?
[15:00] <brainstorm> no, the repo is not mine, it's a third party package
[15:00] <brainstorm> seems I cannot circumvent it easily :_/ "get-orig-source did not create file with prefix picard-tools_1.64.orig"
[15:02] <brainstorm> *they* tag things, I try to package it
[15:04] <tumbleweed> brainstorm: but back to the point. If you think the content is going to change before the final release, use a version number that can be superseded by the final release
[15:05] <tumbleweed> such as 1.65~svn
[15:06] <brainstorm> but when 1.65 comes out upstream, I'm gonna be in trouble, isn't it ?
[15:07] <tumbleweed> ~ is special. x~y < x < x.1
[15:07] <brainstorm> http://paste.ubuntu.com/900594/
[15:08] <brainstorm> isn't there any other way to modify rules to avoid the svn rev hack ?
[15:08] <brainstorm> full debian/rules : http://paste.ubuntu.com/900596/
[15:09] <tumbleweed> what hack do you want to avoid?
[15:10] <tumbleweed> the -0-ubuntu1 or -0ubuntu1 are not part of the upstream version
[15:11] <brainstorm> can I use 1.64~svn then ? I just don't want to confuse people with 1.65 when it's not out there :-/
[15:13] <arand> 1.64~svn << 1.64  So that's likely not what you want
[15:15] <Laney> ~svn is the standard way of denoting this situation "almost 1.65"
[15:15] <arand> Maybe 1.64+svn, but if upstream calls it 1.65 in their VCS I don't see the point in not using 1.65~svn.
[15:15] <brainstorm> ok, I'll try that way then, thanks guys !
[15:21] <brainstorm> I guess it needs more work still… http://paste.ubuntu.com/900618/ :-S
[15:22] <tumbleweed> brainstorm: you forgot to add an entry in your changelog that matched
[15:23] <brainstorm> picard-tools (1.65~svn) oneiric; urgency=low ?
[15:24] <brainstorm> or 1.65~svn-1ubuntu1 ?
[15:25] <tumbleweed> the socond option. This isn't a native package
[15:25] <Laney> you might want to include the revision number
[15:25] <Laney> also 0ubuntu1
[15:25] <tumbleweed> Laney: he says this comes from a tag
[15:26] <brainstorm> right, seems that I've to change debian/rules as well :-S: svn: URL 'http://picard.svn.sourceforge.net/svnroot/picard/tags/1.65~svn' doesn't exist
[15:29] <tumbleweed> right
[15:30] <brainstorm> yay ! .changes and all generated :D thanks !
[15:31] <tumbleweed> np
[16:43] <pabelanger> Hmm, looks like a problem when installing redmine
[16:43] <pabelanger>  redmine : Depends: ruby-rack (>= 1.4.0) but 1.3.5-1 is to be installed
[16:43] <pabelanger> this is precise
[16:47] <pabelanger> bug 965484
[16:47] <ubottu> Launchpad bug 965484 in redmine (Ubuntu) " redmine : Depends: ruby-rack (>= 1.4.0) but 1.3.5-1 is to be installed " [Undecided,New] https://launchpad.net/bugs/965484
[16:47] <pabelanger> If a bug manager wants to triage that to high, since redmine is broken on 12.04
[16:48] <kklimonda> done, I'll take a look at it
[16:49] <pabelanger> kklimonda: great, thanks
[16:53] <pabelanger> Heh, looks like it was updated yesterday.  That explains why it worked on Friday and not today
[17:31] <shadeslayer> \o
[17:32] <shadeslayer> I was wondering if someone could help me with this FTBFS :https://launchpadlibrarian.net/89579030/buildlog_ubuntu-precise-armel.soqt_1.5.0-2_FAILEDTOBUILD.txt.gz
[17:32] <shadeslayer> I understand what's wrong, just don't know how to proceed with a fix
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[17:57] <micahg> shadeslayer: debfx has been sending some of those fixes to Debian, I'd suggest reviewing precise-changes to find some of those or maybe look in the BTS for patches he  reported
[17:58] <shadeslayer> will do, any package that comes to mind?
[17:59] <jtaylor> barry: can you review my scipy3 patch? debian bug 664785
[17:59] <ubottu> Debian bug 664785 in python-scipy "please add python3 packages" [Wishlist,Open] http://bugs.debian.org/664785
[17:59] <barry> jtaylor: sure
[18:00] <jtaylor> I'd really like that in precise, but the maintainers seem quite unresponsive :/
[18:00] <jtaylor> known issues: numpy3 versioned depends are unecessary and there is a python/ in rules which should be python3
[18:00] <debfx> shadeslayer: it's the usual qt uses GLES but the package also has direct GL calls problem
[18:01] <shadeslayer> debfx: right, but how did you fix it? :)
[18:01] <shadeslayer> I figured out that much ...
[18:01] <debfx> the only thing you can do is to disable those
[18:01] <debfx> however often that's not possible
[18:02] <shadeslayer> debfx: http://paste.kde.org/446744/ << this is what it looks like around the line where it fails
[18:05] <debfx> shadeslayer: I recommend talking to upstream about supporting Qt with GLES
[18:06] <shadeslayer> upstream of soqt?
[18:06] <debfx> yes
[18:07] <shadeslayer> alright
[18:08]  * shadeslayer adds it to his list
[18:09] <shadeslayer> debfx: btw, ever had to deal with plasma active?
[18:09] <debfx> no
[18:09] <shadeslayer> ok
[18:15] <swick> hey, i want to fix https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/949606 but I am completly new to it
[18:15] <ubottu> Launchpad bug 949606 in mesa (Ubuntu) "64 bit dev packages should include 32 bit .so library file" [Medium,Triaged]
[18:15] <jtaylor> mesa may not be the best place to start :/
[18:16] <swick> where to start then?
[18:17] <jtaylor> a breif glance at that bug it seems that the -dev package should be changed to be made coinstallable
[18:18] <broder> it actually looks like libglu1-mesa-dev could be marked multiarch: same
[18:18] <broder> i just grabbed the binaries and i'm not seeing any difference
[18:19] <jtaylor> what was the consensus in debian on what to do with identical files in multi arch packages?
[18:19] <jtaylor> is that still the intended way or just "works by accident"
[18:21] <broder> marking -dev packages multiarch: same if none of the headers are generated at build-time is acceptable
[18:21] <broder> there's no consensus on what to do if the headers change across architectures
[18:21] <broder> the eventual solution will probably involve /usr/include/x86_64-linux-gnu et al, but last i checked that hadn't yet been approved as a policy addendum
[18:22] <jtaylor> wasn't dropping this feature and moving everything to arch qualified paths/suffix on the table at one point?
[18:22] <jtaylor> including stuff like debian changelog
[18:22] <jtaylor> I only read about half the thread :/
[18:22] <broder> i don't believe in reading debian-devel, so i'm not totally sure :)
[18:22] <jtaylor> (which where already ~ 50 mails ...)
[18:24] <swick> now I understand why it's not a good place to start :D
[18:24] <debfx> shadeslayer: looks like libcoin needs to be ported to gles first
[18:24] <jtaylor> swick: depends on your experience and patience, it is a core package and might be quite complex (I did not look at it)
[18:25] <jtaylor> also proper multiarch packaging is still a partially undefined subject
[18:26] <jtaylor> do you have any particular questions?
[18:28] <swick> well, where do I find all information about it?
[18:29] <jtaylor> on multiarch or packaging in general?
[18:29] <swick> both ;)
[18:30] <jtaylor> http://www.debian.org/doc/manuals/maint-guide/
[18:30] <jtaylor> http://wiki.debian.org/Multiarch/Implementation
[18:30] <swick> thanks :)
[18:38] <shadeslayer> debfx: @_@
[18:48]  * tumbleweed 's DSL just got activated in his new flat. After a month on 3G, I'd almost forgotton what real connectivity feels like
[18:55] <barry> jtaylor: it looks fine from visual inspection, though i haven't tried to build it.  if i were the maintainer, i'd probably ask you to split up the big override_dh_auto_install rule into smaller rules for py2 and py3 (or i might have done that myself ;).  i hope the maintainers can get back to you soon.  if not, let's get this uploaded to ubuntu early in the q-cycle (i.e. not wait for debian)
[18:55] <jtaylor> not p? :(
[18:56] <barry> jtaylor: well, if you can get the NEW packages past an admin archive <ahem>scottk</ahem>, i'd be all for it
[18:56] <barry> jtaylor: have you perhaps built it in a ppa?
[18:56] <jtaylor> only locally
[18:58] <jtaylor> ScottK is open to it given good review, bug960595
[18:59] <barry> jtaylor: i could stick it in my ppa if you don't have one.  or maybe i should just build it locally and see.  if that works okay, would you want me to sponsor it?  the new package would still have to be approved, and i'm certain whether that would happen this late in the cycle.
[18:59] <barry> jtaylor: otoh, it has a low possibility of breaking anything
[18:59] <barry> jtaylor: do an ffe and attach this to the bug as a branch
[19:00] <jtaylor> Its universe, so I can upload it myself
[19:00] <barry> jtaylor: awesome (on both counts)
[19:00] <barry> jtaylor: let me just build and test install here locally.  i'll comment on the bug
[19:02] <micahg> bdrung: I assume you got the vlc upgrade bug I gave  you?
[19:03] <bdrung> micahg: yes, but i still have to figure out the reason for it
[19:03] <micahg> ok
[19:03] <bdrung> i would complain about getting help
=== shadeslayer_ is now known as shadeslayer
[19:22] <ScottK> jtaylor and barry: As long as barry reviews and approves the diff, I'll do the new stuff.
[19:22] <ScottK> barry: Would you please file an FFe to sync flufl.enum.
[19:23] <barry> ScottK: +1, and +1
[19:23] <ScottK> Great.
[19:23] <barry> i just want to test jtaylor's patch locally and will add a bug comment
[19:23] <ScottK> Then you can get to work on the other flufl pacakges ..
[19:24] <barry> ScottK: to make the -doc changes right?  (i haven't looked at the debbugs yet)
[19:24] <ScottK> barry: I'm more worried about you doing the build system changes (they all seem to have the same issues as enum, but that too.
[19:24]  * ScottK didn't file bugs for it.
[19:25] <barry> ScottK: sure, i'll look at that.  i've not done debian uploads directly yet, so that'll be a fun experience too
[19:26] <ScottK> You need DM-Upload-Allowed in the packages first for that.
[19:26] <ScottK> You can upload flufl.enum now, but not yet the rest.
[19:26]  * barry nods
[19:38] <barry> jtaylor: a local build failed for me: http://paste.ubuntu.com/901024/
[19:38] <barry> jtaylor: but maybe i applied the patch incorrectly.  could you please push a branch and attach it to the ffe?
[19:38] <jtaylor> should I also reduce the duplication a bit?
[19:38] <barry> jtaylor: that would be great
[19:39] <jtaylor> the problem with that is I don't know what the maintainers prefer
[19:39] <jtaylor> for loop, xargs make substitution ...
[19:39] <barry> jtaylor: yeah, dtrt for precise now, and you can worry about sync'ing back to the maintainers preferences in debian, then sync'ing to ubuntu.
[19:40] <jtaylor> hm that failure is a real bug, why didn't it occor on my machine o_O
[19:41] <barry> jtaylor: that's always the mystery. :)  anyway, i'll leave this for now, but ping me when you have something new for me to look at
[19:41] <jtaylor> I probably changed some things after build and did not rebuild ...
[19:41] <jtaylor> k
[19:43] <barry> jtaylor: branches are easier for me to review than debdiffs, if possible
[19:43] <jtaylor> branching scipy will take a while :/
[19:43] <barry> ;/
[19:43] <jtaylor> do you know how many mb?
[19:43] <barry> if it really sucks, i'll deal with the debdiffs
[19:43] <jtaylor> just so I can guess how long it will take
[19:44] <barry> .bzr in my shared repo is 16M
[19:46] <jtaylor> gna python update too another 30mb to download for testbuilds ._.
[19:47] <jtaylor> who the hell links against the static libpython that we need that :(
[20:15] <jtaylor> barry: branch: lp:~jtaylor/ubuntu/precise/python-scipy/python3 , but I haven't test built it yet so no idea if it even works
[20:15] <barry> jtaylor: cool.  i'll try it too.  we can race. :)
[20:17] <jtaylor> I think the package builds python2 stuff twice ...
[20:17] <barry> jtaylor: ah
[20:18] <jtaylor> one should probably override dh_auto_build to do nothing, it will be done in install later
[20:19] <barry> i guess this is a case where you're not sure what the maintainers preference would be, so they may want you to do things differently.  you'll just have to deal with that when you get the package into debian.  sigh.
[20:27] <jtaylor> uhoh build failure
[20:28] <jtaylor> why doesn't vim syntax highligh correctly :(
[20:28] <barry> jtaylor: as an emacs user, i will refrain from snarky comments :)
[20:31] <jtaylor> barry: pushed the changes if you want to restart, but you may want to wait until it works on my machine to not waste your time
[20:32] <jtaylor> its fine if its not done today I guess
[20:32] <barry> jtaylor: i can wait, i'm in a meeting atm
[20:34] <jtaylor> the great thing about the bug was that it was a stray -- in the beginning of a line so it did not abort on the first case but went trough all iterations and failed then ...
[20:44] <jtaylor> arg that one won't work either
[20:44] <jtaylor> I should be more careful
[20:49] <jtaylor> barry: you can stop your build its a bit more tricky to remove the duplciation
[20:49] <jtaylor> requires changes to how stuff is installed
[20:50] <barry> jtaylor: meeting is ongoing so i'm not building atm.  i'll just wait until you ping me.  i'll be here for several hours still (and there's always tomorrow)
[20:51] <jtaylor> I think its best to just leave the duplication in, removing it is a bit invasive and could potentially complicate merging again in q
[20:53] <barry> jtaylor: i guess that's the other side of it. the bigger the delta now the more pain it will be to sync up again later
[20:53] <jtaylor> let me think about it a bit, maybe the maintainers reply until tomorrow :)
[20:53] <barry> cool :)
[20:58] <jtaylor> hm doing it requires some more or less large build system changes also for python2
[20:59] <jtaylor> I don't think ScottK will like it, I promised the py3 packages stay untouched :)
[20:59] <jtaylor> py2
[20:59] <ScottK> I'm fine with changing both if it's a better solution.
=== adam_g_ is now known as adam_g
[22:13] <jtaylor> barry: pushed changes that should work though I probably will not have time to check the results of a clean build today
[22:39] <jtaylor> nope still not working