[00:00] <sarnold> arosen: aha, debconf(7) (from debconf-doc) suggests DEBIAN_FRONTEND=noninteractive
[00:00] <maxb> passing it am empty argument may work, e.g. : dch -r ""
[00:00] <maxb> sarnold: dch doesn't use debconf
[00:00] <sarnold> oh hell, wrong thing :)
[00:00] <sarnold> sorry arosen :)
[00:01] <arosen> I tried export DEBIAN_FRONTEND=noninteractive same thing :/
[00:01] <slangasek> if you pass it an explicit string to use for the changelog entry, it won't prompt for input; for dch -r, the "" also works
[00:05] <arosen> thanks guys!
[00:29] <bdrung> micahg: re debian bug #650348 - would it be okay if dh_xul-ext fail instead of install-xpi?
[00:29] <bdrung> dh_xul-ext does all the version calculation stuff
[00:55] <micahg> bdrung: sure, that's fine, the idea was to have the build fail on it :)
[00:55] <bdrung> micahg: okay, i will add that support (probably tomorrow)
[00:56] <micahg> bdrung: it would also be nice to calculate proper binary dependencies for binary addons, but idk if we can do that
[00:57] <bdrung> micahg: can we distinguish binary from non-binary extensions?
[00:58] <micahg> arch: all vs arch:any?
[01:01] <bdrung> that might work. on what does these binaries depend on?
[01:02] <bdrung> micahg: isn't dh_shlibdeps enough?
[01:03] <micahg> bdrung: we don't have symbols files for Firefox/Thunderbird as they're not "shared libraries" per se
[01:07] <bdrung> micahg: against what kind of api/abi are the binary addons compiled?
[01:07] <bdrung> which libraries?
[01:08] <micahg> bdrung: thunderbird/firefox, I'm not sure offhand about specific
[01:08] <bdrung> even if Firefox/Thunderbird do not have "shared libraries", you could maintain a shlibs file that make dh_shlibdeps work.
[01:09] <bdrung> s/\./?/
[01:09] <bdrung> s/\./, couldn't you?/
[01:09]  * bdrung thinks that it's time for bed.
[01:09] <micahg> yeah, could probably use something similar to libav-extraa
[01:09] <micahg> just the one a there
[01:10] <micahg> it's pretty simple though, for Firefox/Thunderbird and I think Seamonkey, an increment in the first or second number in the version breaks ABI
[01:12] <bdrung> micahg: what does libav-extra do?
[01:12] <micahg> has a SHLIBS variable in debian/rules, but I don't think we even need that
[01:16] <bdrung> micahg: dunno if SHLIBS is enough to permit a newer Firefox with an older addon built
[01:16] <micahg> I don't want to use SHLIBS as it seems like overkill
[01:17] <micahg> if it's a binary addon, it works with only one major.minor version
[01:17] <bdrung> which binary addons do we have in the archive?
[01:18] <micahg> enigmail and lightning-extension (which was just solved)
[01:18] <micahg> lightning, not enigmail
[01:24] <bdrung> libcalbasecomps.so from lightning-extension links against libxpcom.so, libmozalloc.so, libxul.so
[01:25] <bdrung> micahg: these files are in /usr/lib/firefox or /usr/lib/thunderbird
[01:25] <micahg> yes
[01:25] <micahg> well, in Ubuntu
[01:26] <bdrung> what does upstream?
[01:26] <micahg> same, xulrunner on its own isn't officially supported anymore
[01:27] <micahg> idk what Debian does at this point though
[01:28] <bdrung> http://packages.debian.org/search?suite=default&section=all&arch=any&searchon=contents&keywords=libxpcom.so
[01:30] <bdrung> it seams that icedove, iceape ships their own libraries, but iceweasel uses xulrunner
[01:30]  * bdrung will go to bed.
[01:32] <bdrung> micahg: restricting the dependency for binary addons should be doable, but there is probably no perfect solution (unless upstream uses proper so versioning)
[01:32] <micahg> bdrung: it's not a shared library anymore, why should they care? (and binary addons are discouraged at this point)
[01:33] <bdrung> micahg: so binary addons will go away?
[01:33] <micahg> idk about that :), they're discouraged though as the interface isn't stable
[07:49] <dholbach> good morning
[07:58] <didrocks> hey dholbach
[07:58] <dholbach> hey didrocks
[08:41] <pitti> Good morning
[09:26] <xnox> tumbleweed: ok, I will look at remerging and uploading that.
[09:32] <xnox> tumbleweed: never it's fully up to date in raring....
[09:41] <tumbleweed> xnox: yeah, nevermind me
[10:09] <pitti> jodh: good morning
[10:09] <pitti> jodh: so I have a job which does something like
[10:09] <pitti> exec /my/program >> /var/log/retracer.log 2>&1
[10:10] <pitti> jodh: is there any chance to make this actually work somehow? it seems upstart does something to stdout and stderr to make this not work (xnox just confirmed that)
[10:10] <pitti> jodh: I tried "script" instead of exec, and "console output", but that doesn't help
[10:12] <xnox> pitti: exec /my/program &>> /var/log/retracer.log ?
[10:12] <pitti> same result with &>>
[10:16] <pitti> jodh, xnox: I also tried dropping the redirection and use "console log", but /var/log/upstart/ doesn't have anything
[10:17] <xnox> pitti: script
[10:17] <xnox>     myawesomeprog 2>&1 | logger -t myawesomeprog
[10:17] <xnox> end script
[10:17] <jodh> pitti: wfm: http://paste.ubuntu.com/1414330/
[10:18] <pitti> jodh: that's precise, maybe it doesn't work there?
[10:21] <zequence> Is there a reason for extra and partner repos not to be included when installing using wubi.exe?
[10:23] <pitti> jodh: when I change stuff in /etc/init/, upstart should pick that up right away, right?
[10:30] <jodh> pitti: this works in precise too. assuming you haven't invalidated the config file, yes Upstart picks changes up immediately. Use init-checkconf /etc/init/myjob.conf to establish that.
[10:31] <jodh> pitti: the only other case where changes to .conf files won't be picked up is on the live cd.
[10:34] <jodh> pitti: well, to be more precise in overlayfs envs (bug 882147)
[10:35] <pitti> jodh: no, it's a standard precise VM in juju without overlays
[10:38] <jodh> pitti: does /var/log/upstart/ actually exist? There was a bug a while back where it wasn't being created in cloud images.
[10:38] <pitti> jodh: yes, it has gssd.log and statd.log
[10:39] <jodh> pitti: ok - great.
[10:41] <jodh> pitti: any chance I can see the .conf file? Also, see: http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
[10:43] <pitti> jodh: http://paste.ubuntu.com/1414378/
[10:43] <pitti> jodh: (sorry, in meeting)
[10:47] <jodh> pitti: I think that redirection is the problem - for /bin/sh it means background process_core.py, whereas I assume you intended it to mean redirect both stdout+stderr to the file?
[10:47] <jodh> pitti: upstart runs all jobs that need a shell using '/bin/sh -e'
[10:48] <pitti> jodh: I also tried with >> log 2>&1
[10:48] <pitti> (in fact that was my first code, xnox suggested trying with &>>
[10:48] <pitti> but right, that's a bashism
[10:49] <pitti> jodh: http://paste.ubuntu.com/1414384/
[10:50] <xnox> ack. /me overuses bashism
[10:50] <jodh> pitti: I guess the script is failing due to the minimal environment that Upstart provides the job. Try adding 'set' or 'env' calls just prior to calling the python script.
[10:50] <jodh> pitti: or try my cookbook test mentiond above.
[10:52] <pitti> jodh: oh, with exec >? trying
[10:53] <jodh> pitti: silly question maybe, but is the script executable? Also, what's the first line of the python script?
[10:53] <pitti> #!/usr/bin/python
[10:53] <pitti> jodh: yes, it is
[10:53] <pitti> jodh: I can call that very command in a shell, and it works
[10:54] <pitti>   exec >> /var/log/retracer.log 2>&1
[10:54] <pitti> that doesn't seem to work either
[10:54] <jodh> pitti: when you say 'in a shell', you mean you've confirmed that the 'env -i' invocation works?
[10:55] <pitti> jodh: no, I mean when I ssh, sudo -i, and run that command there
[10:55] <jodh> pitti: please try the cookbook method.
[10:56] <pitti> jodh: isn't that 17.4.2? that's what I tried
[10:56] <pitti> I also tried env -i /var/retracer/daisy/process_core.py [...]
[10:56] <jodh> pitti: no - http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
[10:57] <pitti> (bbl, discussion here)
[11:16] <bdrung> micahg: dh_xul-ext: xul-ext-test-package contains an invalid version range for {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
[11:16] <bdrung> dh_xul-ext: minVersion <= maxVersion is required, but 10 > 8.
[11:16] <bdrung> dh_xul-ext: xul-ext-test-package contains an invalid version range for {92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
[11:16] <bdrung> dh_xul-ext: minVersion <= maxVersion is required, but 2.4 > 2.0.
[11:16] <bdrung> micahg: is this error message verbose enough or is something missing?
[11:48] <pitti> jodh: re
[11:48] <pitti> jodh: so that recipe means to run the service through nohup env -i?
[11:50] <jodh> pitti: yes.
[11:51] <jodh> pitti: what actually happens when you attempt to start this job? What output from start(8) do you get?
[11:51] <pitti> $ sudo start retracer
[11:51] <pitti> retracer start/running, process 18783
[11:51] <pitti> jodh: still no change with
[11:52] <pitti> http://paste.ubuntu.com/1414489/
[11:52] <pitti> jodh: I'm beginning to suspect that the .conf file is not being re-read correctly, as none of the changes that I did in the past hour had any visible effect
[11:52] <pitti> oh, it does; I now see /bin/sh -e nohup env -i ... in ps aux
[11:52] <pitti> so reloading works
[11:52] <jodh> pitti: sorry, what I mean is please run the exact example using nohup and env -i in the cookbook on the command-line, not in the job.
[11:53] <jodh> pitti: well, to check that, just copy your updated job to some new name and start that job.
[11:54] <jodh> pitti: or try 'sudo telinit q'
[11:54] <jodh> pitti: you should also do 'sudo initctl log-priority debug' before attempting to start the job and then check /var/log/syslog
[11:55] <jodh> pitti: is this python script forking by any chance? maybe you could just get a simple hello-world python script to convince yourself that that works as expected on this system?
[11:57] <pitti> I'll try a job which is a simple echo
[12:00] <pitti> so simple echo works
[12:02] <jodh> pitti: a python script doing an echo?
[12:02] <pitti> jodh: ok, thanks; the script doesn't fork, but it might do something funny
[12:02] <pitti> I tried python -c "import sys; sys.stderr.write('world\n')" >> /tmp/logtest.txt 2>&1
[12:02] <pitti> and that works, too
[13:39] <_jmp_> micahg: ping
[13:41] <_jmp_> micahg: unping sorry
[13:52] <dholbach> can somebody please reject https://code.launchpad.net/~chilicuil/ubuntu/raring/cdo/fix-1023329/+merge/135245?
[13:52] <dholbach> (explanation in the last comment)
[13:52] <pitti> kicked
[13:56] <dholbach> thanks pitti
[13:57] <arges> micahg, infinity : hey wondering about bug 943502 still. Should I re-request a Backport or go for an SRU?
[14:03] <ev> mpt: http://www.microsoft.com/en-us/pixelsense/default.aspx
[14:10] <ev> pitti: https://errors.ubuntu.com/api/1.0/most-common-problems/?limit=0&format=json
[14:15] <ev> bdmurray, pitti, mpt, xnox: https://bugs.launchpad.net/daisy/+bug/1052954/comments/2 and https://bugs.launchpad.net/daisy/+bug/1052954 - I'm having a hard time understanding the exact contours of this algorithm. Help wanted :)
[14:38] <mlankhorst> nooo why did synergy have to update :(
[14:47] <mlankhorst> pinned it back to 1.3.8, stay!!
[14:53] <mpt> ev, bug 1087290
[15:03] <micahg> arges: I think it's still a backport (new feature), I was just waiting for a signoff on the testing...did I miss it?
[15:06] <micahg> arges: ah, if infinity said it's SRU worthy, run with that, if it was an ARIN change, that makes sense to SRU
[15:06] <micahg> (sorry, I check IRC before E-Mail :))
[15:14] <arges> micahg, cool its no problem, I think SRU makes sense in this case too. Sorry about all the back and forth on this bug.
[15:53] <p0s> i want to help with packaging software for which no packages are available at all yet. can someone give me a link to an official guide for packaging new stuff?
[15:54] <highvoltage> p0s: https://wiki.ubuntu.com/PackagingGuide - and perhaps #ubuntu-motu and #ubuntu-packaging might be better channels to ask about that
[15:55] <p0s> highvoltage: thank you
[15:55] <highvoltage> (or as that page rightly points out, http://developer.ubuntu.com/packaging/html/ )
[16:24] <burlak> Guys, I'd like to contribute in ubuntu project but i have no idea how.
[16:25] <penguin42> burlak: What do you know? Programming? Art? Docs?
[16:25] <burlak> I'm RTOS developer
[16:25] <burlak> penguin42: but I can do anything.
[16:26] <penguin42> hmm ok
[16:26] <burlak> penguin42: can I send my resume to someone?
[16:27] <penguin42> burlak: Well not really unless you're looking for a job
[16:27] <burlak> penguin42: I have a job :D
[16:28] <penguin42> burlak: http://www.ubuntu.com/community/get-involved
[16:28] <burlak> penguin42: is there somewhere something like project list so i can choose the one which is the best for me?
[16:28] <burlak> penguin42: thx
[16:32] <hallyn> if pkg A Breaks: B (<< ${source:Version}) then pkg A simply won' tinstall.  If it Conflicts, will it remove pkg B before installing A?
[16:33] <stgraber> hallyn: I think http://www.debian.org/doc/debian-policy/ch-relationships.html should answer any question you have :)
[16:34] <hallyn> no i'm looking at that
[16:34] <stgraber> hallyn: but basically you probably want a Breaks + Replaces if the goal is to have a package replace another
[16:34] <hallyn> oh, yes
[16:34] <hallyn> stgraber: that is not sufficing
[16:34] <hallyn> let me give a fuller version :)
[16:34] <cjwatson> Conflicts is stronger than Breaks
[16:35] <hallyn> meaning it will uninstall the conflicting pkg?
[16:35] <cjwatson> Conflicts: A and B may not be unpacked at the same time
[16:35] <hallyn> lemme go read the doc
[16:35] <cjwatson> Breaks: A and B may not be configured at the same time
[16:35] <hallyn> ok that sounds like something in eed, but still perhaps not enough
[16:35] <cjwatson> apt often has a choice about what to do and it depends on scoring
[16:35] <cjwatson> Policy has general instructions on what you should do in a variety of situations
[16:35] <cjwatson> So you should definitely read that first
[16:35] <hallyn> ok, will do before babbling more here, thanks
[17:28] <brendand> mvo, mpt - i've just been watching a user focused video on youtube where someone was trying to use software center to actually locate an app to use. would there be any harm in having an 'open' button on an apps page in software-center (kind of like on android)?
[17:29] <mpt> brendand, the issue has always been that people wouldn't then learn how to launch it outside of USC
[17:29] <mpt> brendand, that's why the app icon flies into the Launcher, to show you where to find it.
[17:29] <mpt> brendand, did the icon fly into the Launcher in the video?
[17:30] <xnox> mpt: it would not have if an app doesn't have desktop file =)))))
[17:30] <mpt> xnox, it's unlikely that's the kind of app brendand is talking about
[17:30] <xnox> mpt: true.
[17:31] <brendand> mpt - so the particular circumstance here was someone asked to find the calculator app
[17:31] <mpt> brendand, do you have a link to the video?
[17:31] <brendand> mpt - gcalc is already there, so no flying
[17:31] <brendand> mpt, https://www.youtube.com/watch?feature=player_detailpage&v=PgGbZfR6Vec#t=641s
[17:32] <mpt> ta
[17:34] <mpt> ergh, that LibreOffice Calc name+icon keeps coming up as a usability problem
[17:34] <brendand> something that always strikes me from those videos is how it often takes people a long time to discover the dash
[17:34] <brendand> seems like there should be a big arrow pointing at it on first boot
[17:35] <mpt> Yes, there hasn't been much effort into that
[17:35] <mpt> I know there were proposals for a different icon
[17:35] <mpt> e.g. a home icon instead of the Ubuntu logo
[17:36] <mpt> brendand, "I thought all those things were installed." She was a bit misled by the moderator, I think. :-)
[17:37] <mpt> He gave the impression it was like the Applications folder
[17:37] <brendand> mpt, that's true
[17:37] <mpt> "I just stumbled across that" -- the Dash button
[17:39] <penguin42> mpt: I've seen some experienced people also have difficulty noticing it was special
[17:39] <mpt> yeah
[17:39] <mpt> Bug 552920 makes an appearance at https://www.youtube.com/watch?feature=player_detailpage&v=PgGbZfR6Vec#t=14m06s
[17:43] <brendand> also, i know it's a touchy subject but it seems to bug a lot of beginners that the window controls are hidden by default
[17:46] <mpt> brendand, it bugs me too :-)
[17:47] <brendand> have there been any experiments with perhaps having the window controls always there alongside the title/menus?
[17:48] <mpt> brendand, not publicly
[17:57] <penguin42> there seem to be lots of things where the fortify stuff triggers in Ubuntu for trivial (non-exploitable) 1 char overruns, that probably never actually cause any harm; is it normal to raise Debian bugs for those even though they don't trigger in Debian?
[17:58] <slangasek> penguin42: there are real-world exploits demonstrating that a 1-char overrun is sufficient to compromise the system
[17:59] <slangasek> if the overflow exists in Debian, certainly it's reasonable to raise a bug against Debian
[17:59] <penguin42> slangasek: Yep; I just keep finding 1 char overflows in static data where you can see the compiler will have padded the allocation to the next word so it'll never overflow
[17:59] <slangasek> (providing sufficient additional information to let the Debian maintainer reproduce and understand the issue, of course)
[18:00] <penguin42> sure
[18:00] <slangasek> penguin42: the allocation may be padded, but is it guaranteed to be zero-filled?
[18:00] <mvo> brendand: what mpt said, impleenting open is trivial (and there is a branch for this already) - there is also work to make the fly-in feature better
[18:00] <penguin42> slangasek: Not necessarily a problem; I just keep finding ones where someone has forgotten the space for the \0 and we fall over when it copies the initial string in
[18:01] <slangasek> ah
[18:01] <mvo> brendand, mpt:  lp:~mvo/unity/sc-launcher-integration-fixes  <- that will hopefully make the fly in feature better
[18:01] <penguin42> slangasek: Although there is one which turned out to be a y2k problem because the date was being printed as 2112 :-)
[18:01] <penguin42> sorry, 20102 I think
[18:01] <slangasek> penguin42: well, the path of least resistance may still be to clean this up rather than trying to argue with the compiler.  Debian packages should be using fortify too nowadays, though it does require debian/rules to be properly constructed
[18:02] <brendand> mvo, i'm playing devils advocate, but i don't necessarily see people continuing to use the hypothetical 'open' button in swc once they discover the dash
[18:02] <brendand> but i'm absolutely no usability expert
[18:02] <penguin42> slangasek: Yep; most of these things are in universe packages that have just always failed in ubuntu for years
[18:04] <mvo> brendand: I personally would not mind getting the open-button branch landed, but its not my decision
[18:05] <mvo> lets see what the new fly-in branch will do :)
[18:05] <cjwatson> I'm surprised there are all that many; there were 83 failures total in quantal/i386, according to the rebuild test a little before release
[18:05] <mvo> I hope it fixes the problem
[18:05] <cjwatson> I can believe there are some, certainly
[18:06] <penguin42> slangasek: Like bug 1033250 (which I've linked a branch against)
[18:17] <cjwatson> xpilot-ng doesn't seem to have failed in the rebuild test ...
[18:17] <cjwatson> Ah, failing to run not to build
[18:19] <penguin42> cjwatson: Yeh it's a fail to do internet games, it's a 1 char overflow (they have a magic constant of 10000 for the pingtime to mean there was a problem, but they try to print the ping time into a 5 char buffer)
[18:20] <ScottK> Adri2000: I see you're the Debian maintainer of actionaz.  It fails to build with the new opencv in both Debian experimental and Ubuntu raring.  I was wondering if you could have a look at it.
[18:27] <Adri2000> ScottK: sure, I'll have a look
[18:27] <ScottK> Adri2000: Thanks.
[18:38] <hallyn> stgraber: ok, things are a tiny bit better now.  apt-get dist-upgrade with qemu-kvm installed does:  qemu-kvm depends on qemu-system (which conflicts/replaces/provides qemu-kvm which itself becomes a metapkg) which recommends qemu-utils which conflicts/replaces qemu-kvm (has to bc qemu-io is in both) - so qemu-kvm gets removed, removing the qemu-system dependency, so you end up with only qemu-utils installed.
[18:38] <hallyn> i get the feeling i'm making things more complicated than they need to be
[18:38] <cjwatson> Trying to forcibly remove transitional packages is usually a mistake
[18:39] <ricotz> infinity, hi, did you had a look at https://bugzilla.gnome.org/show_bug.cgi?id=687265#c9 ? it is pretty much needed if a newer glib/gstreamer lands
[18:39] <psusi> andreas__: why does the upstream landscape-client have a debian/ directory?  isn't this wrong?
[18:39] <hallyn> cjwatson: i want to remove the old (real pkg) qemu-kvm, replaced with the new (meta) one
[18:39] <cjwatson> Err, that's an upgrade not a removal ...
[18:39] <andreas__> psusi: we have it in the bzr branch, because we do daily builds, but the tarball doesn't include it, and the ubuntu package has its own
[18:40] <hallyn> cjwatson: i don't know how to express that in debian/control
[18:40] <cjwatson> You're moving files from qemu-kvm to qemu-system/qemu-utils, yes?
[18:40] <hallyn> yup
[18:40] <infinity> hallyn: You can't force removal of yourself like that.
[18:40] <cjwatson> Then qemu-system/qemu-utils Breaks/Replaces: qemu-kvm (<< first-version-not-to-contain-those-files)
[18:40] <psusi> andreas__: I see.. so if I'm patching it, should I just patch the sources without bothering with quilt and submit a merge proposal?
[18:41] <cjwatson> Don't use Conflicts
[18:41] <hallyn> cjwatson: breaks/replaces didn't work: it simply refused to install qemu-utils
[18:41] <psusi> andreas__: and should I update the changelog?
[18:41] <cjwatson> Then you made some other mistake
[18:41] <andreas__> psusi: yes, worry just about the ubuntu package, we merge back to our branch what is needed
[18:41] <hallyn> likely
[18:41] <cjwatson> The usual mistake is to forget to version things correctly
[18:41] <infinity> hallyn: As you described it, that's just not going to work.
[18:41] <hallyn> i did also change versioning just now.
[18:41] <psusi> andreas__: ok
[18:41] <hallyn> infinity: even if i do breaks/replaces the way cjwatson says?
[18:42] <cjwatson> Change it back to Breaks and make sure the << versioning is there.  That should be enough.
[18:42] <infinity> hallyn: If you do breaks/replaces (versioned!) with no conflicts, it'll be fine.  But it won't result in what you thought it would.
[18:42] <cjwatson> I'm assuming that qemu-io is not in the new version of qemu-kvm.
[18:42] <hallyn> cjwatson: ok, thanks.
[18:42] <infinity> hallyn: As in, it won't remove qemu-kvm.  Which is fine.
[18:42] <hallyn> no
[18:42] <hallyn> ok lemme try that again.  thanks
[18:43] <hallyn> (before i was doing breaks qemu-kvm << ${source:Version},  now im' doing <= (the-old-version)
[18:43] <hallyn> maybe that's what i was doing wrong with the breaks.
[18:43]  * hallyn goes to try
[18:43] <cjwatson> As I say, it should be << first-version-not-to-contain-those-files
[18:43] <infinity> hallyn: Either of those works, but being strict is more correct, yes.
[18:43] <cjwatson> Not ${source:Version}, and not <= (otherwise trouble with derived versions)
[18:44] <infinity> hallyn: << source:Version still would have "worked", though, in your testing, so something *else* was wrong on top of that.
[18:44] <hallyn> that's what i'm seeing in what cjwatson says too.  grr
[18:44] <cjwatson> Yeah.  If it still doesn't work, post `debc foo.changes`
[18:44] <cjwatson> (of the built version)
[18:45] <hallyn> i can't test this just with dpkg right?  ihave to go through ppa and apt-get?
[18:45] <infinity> No need to use a PPA, but yes, a local apt repository is a saner test.
[18:45] <cjwatson> You certainly *can* test it with dpkg but it may not be as good a test
[18:45] <infinity> Still, "dpkg -i foo bar baz" isn't an awful first test.
[18:45] <infinity> It just misses out on some pseudo-intelligent ordering apt might do.
[18:47] <infinity> hallyn: Can I just see your control file?  This might be easier to help with if it's not being turned into IRC English.
[18:48] <hallyn> infinity: actually i just caught a mistaken << last-bad-version in place of <= , that might be why it broke this time.  but i'm in the process of changing it to << first-good-version as cjwatson said
[18:48] <hallyn> i'll pb the previous control file in just a min
[18:49] <hallyn> infinity: well http://paste.ubuntu.com/1415346/ is the version I'm about to push
[18:50] <hallyn> infinity: http://paste.ubuntu.com/1415348/ is the last bad version - note i had bad comparisons in qemu-system replaces
[18:50]  * hallyn hopes the new version finally does the right thing
[18:51] <infinity> Looks like it should, assuming the versions are all correct.
[18:52] <infinity> I went cross-eyed at this, though:
[18:52] <infinity> Breaks:  qemu-system (<< 0.12.4+dfsg-4), qemu-kvm (<< 1.2.0-z-dfsg-1), qemu-common (<< 1.2.0-z-dfsg-1)
[18:52] <infinity> Replaces:  qemu-system (<< 0.12.4+dfsg-4), qemu-common (<< 1.2.0-z-dfsg-1), qemu-kvm (<< 1.2.0-z-dfsg-1)
[18:52] <infinity> (position of -kvm and -common swapped on the two lines makes it a bit harder to notice the matched pairs)
[18:52] <andreas__> psusi: you could make a merge proposal against the landscape-client source code, not worrying about the packaging stuff
[18:52] <hallyn> infinity: d'oh, yeah, i'll change that (for the next upload)
[18:53] <hallyn> one unrelated question - to remove the old /etc/init/qemu-kvm.conf, i gather i need to do that in qemu-system.postinst?
[18:53] <psusi> andreas__: should I do that, or did you say not to worry about it?
[18:53] <hallyn> (it offers a /etc/init/qemu-system.conf which takes the palce of that one)
[18:54] <andreas__> psusi: I meant not to worry about packaging if making a MP against the upstream branch, sorry :)
[18:56] <psusi> andreas__: ahh, ok
[18:57] <arosen> If I do debchange --create --package foo -v  200.1-bar-1; then Run i run dpkg-buildpackage it looks for ../foo_200.1-bar.orig.tar.bz ; I'm wondering why it isn't also searching for the -1 ?
[19:00] <arosen> If I change - to . it works fine. I'll just do that for the version instead.
[19:01] <Adri2000> arosen: because what is after a '-' is the debian revision. the original tarball's name should contain upstream version only. maybe what you are looking for is native package. anyway, #ubuntu-motu is probably better for this kind of questions
[19:05] <ScottK> Adri2000: I saw your comment on #d-devel about the opencv bug.  Could up upload a fixed version to raring?
[19:05] <ScottK> up upload/you upload
[19:09] <Adri2000> ScottK: just with the bug fix right? 2.4.3 seems to have a number of other changes so I'd rather let that to the debian maintainer if we don't want particularly need this specific version now
[19:10] <ScottK> Adri2000: Someone uploaded 2.4 and then blew off the rest of the library transition.  I'm just trying to get everything built.
[19:10] <ScottK> So I'm fine with just the bug fix.
[19:10] <Adri2000> ah I see :)
[19:10] <Adri2000> will do that then
[19:11] <micahg> ScottK: no, there was an attempt at the transition, not sure what happened
[19:12] <ScottK> micahg: Only one of the redepnds was uploaded.
[19:12] <ScottK> And it's FTBFS on armhf
[19:12] <micahg> ScottK: I count 10
[19:12] <ScottK> OK
[19:12] <ScottK> I guess I started with the list of what wasn't done
[19:13] <micahg> I know he was having some issues with it though, not sure what exactly went wrong
[19:14] <ScottK> I'm only trying to get digikam to transition without taking any of the extreme measures I could as an archive-admin or release team member.
[19:14] <micahg> ScottK: there was an attempted rebuild of it yesterday :)
[19:16] <ScottK> It would be nice if someone who knows something about java would look at sikuli
[19:17] <ScottK> It FTBFS for Java'ish reasons unrelated (I think) to opencv
[19:17] <micahg> jamespage: ^^
[19:17] <ScottK> org/sikuli/ide/PreferencesWin.java:499: error: cannot find symbol
[19:17] <ScottK>       DefaultComponentFactory.setTextAndMnemonic(_titleAppearance, I18N._I("PreferencesWin.titleAppearance.textWithMnemonic"));
[19:18] <ScottK> wallch and libav-extras were no-change rebuilds.  I uploaded those
[19:19] <ScottK> Once Adri2000 fixes opencv, he can upload actionaz.
[19:19] <ScottK> Then it'll be down to sikuli and the armhf failure on sivp
[19:33] <infinity> ricotz: I'll get a fix for that in before the weekend.
[19:37] <ricotz> infinity, great, thanks
[20:23] <mterry> @pilot in
[20:43] <jandrusk> Anyone know why libssh2-1 is in repo Universe and not the Main repo?
[20:44] <ScottK> Because nothing in Main needs it in Main.
[20:46] <jandrusk> Doesn't libcurl3-gnutls need it to be compiled with SSH support?
[20:48] <micahg> libssh is in main
[20:51] <hallyn> infinity: alas, the new packages with that versioning gave me http://paste.ubuntu.com/1415560/
[20:52] <jandrusk> Trying to figure out why libcurl is compiled without SSH support.
[20:52] <micahg> who says it is
[20:53] <jandrusk> It's been discussed on the sword-devel mailing list. Is it compiled with SSH support?
[20:54] <jandrusk> Should I just reach out to the libcurl Ubuntu package maintainer?
[20:54] <micahg> hrm, doesn't seem to have it
[20:54] <micahg> jandrusk: I'd suggest asking teh Debian maintainer
[20:54] <jandrusk> micahg: thanks, i will do that.
[20:56] <infinity> micahg: Err, no, asking the Debian maintainer will get him LARTed.
[20:57] <infinity> +  * Resynchronise with Debian.  Remaining changes:
[20:57] <infinity> +    - Drop dependencies not in main:
[20:57] <infinity> +      + Build-Depends: Drop stunnel4 and libssh2-1-dev.
[20:57] <infinity> +      + Drop libssh2-1-dev from binary package Depends.
[20:57] <infinity> ^-- That's an Ubuntu-specific delta.
[20:57] <micahg> jandrusk: ^^ sorry
[20:57] <micahg> infinity: apparently I'm not quite awake yet, thanks
[20:58] <infinity> hallyn: Curious.  Is this source package in a PPA somewhere or something?
[20:58] <infinity> hallyn: I kinda want to take a closer look. :P
[21:04] <hallyn> infinity: yeah, ppa:serge-hallyn/crossc
[21:04]  * hallyn wishing he'd picked a different lp username years ago
[21:05] <infinity> If you don't mind losing all your PPAs, you can always rename. :P
[21:06]  * infinity wonders why there's a sparc cross toolchain in here.
[21:06] <hallyn> and code branches
[21:06] <hallyn> weren't you there last time we discussed that? :)
[21:06] <infinity> Nope.
[21:06] <infinity> Also, on a side note, this version number is crack.
[21:07] <hallyn> infinity: it's workaround for bug 217427 (the cross compiler that is)
[21:07] <hallyn> or, attempt at working toward one...
[21:07] <infinity> It would take more than arch affinity to fix the ability to build sparc packages. :)
[21:08] <hallyn> same for powerpc though
[21:08] <micahg> jandrusk: here's your reason: https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/173783
[21:08] <hallyn> infinity:  as for version #, yes, i've been looking for a solution, dont' have one yet.
[21:08] <infinity> Yeah, I know.  SLOF is currently in that predicament.
[21:08] <hallyn> infinity: the debian version is 1.2.0-dfsg, the ubuntu one is 1.2.0+noroms and 1.2.0-2012something
[21:09] <hallyn> infinity: and we're switching to the debian versions.  so other than switching to 1.3.0 source, i'm not sure how best to force revert to debian versions
[21:09] <hallyn> now i guess i'm not entirely opposed to running 1.2.0 out of a ppa until 1.3.0 comes out and onlys witching archive over then
[21:09] <hallyn> but it seems like there must be a better answer :)
[21:10] <infinity> hallyn: As in, this source is going to be uploaded to Debian as well?
[21:11] <hallyn> infinity: right, this is from the debian qemu team's experimental branch
[21:11] <hallyn> it's the qemu tree to supplant qemu-kvm
[21:12] <infinity> hallyn: Well, I hate to break it to you, but 1.2.0-z isn't higher than 1.2.0+noroms
[21:12] <infinity> hallyn: Which could be your problem here. :P
[21:12] <infinity> hallyn: + sorts higher than -
[21:12] <hallyn> well shoot
[21:13] <hallyn> now i don't even know if i meant to do 1.2.0+z, 1.2.0z, or if i was jsut wrong all along
[21:13] <ScottK> micahg: Considering things like MaaS get accepted directly into Main days before a release, I think that's hardly reason to keep stuff out anymore.
[21:13] <infinity> hallyn: 1.2.0.dfsg-1
[21:13] <infinity> hallyn: Unless there's likely to be a 1.2.0.1
[21:13] <ScottK> Also, it's no longer a young project ... (5 years later)
[21:14] <infinity> hallyn: Or 1.2.0+zzzz+naps+lolcats-1
[21:14] <hallyn> ooh i like that
[21:14] <micahg> ScottK: right, but I don't think the security team would want to support 2 libssh packages
[21:14] <hallyn> infinity: let me try 1.2.0.dfsg-1, thanks.
[21:15] <hallyn> infinity: one other q,
[21:15] <hallyn> am i right that qemu-system.postinst needs to rm /etc/init/qemu-kvm.conf ?
[21:15] <hallyn> (dpkg isn't going to do that for me right?)
[21:15] <slangasek> hallyn: no
[21:15] <hallyn> the file /etc/init/qemu-system.conf will take its place
[21:15] <hallyn> slangasek: no i shouldn't do that, or no it wont' do that for me?
[21:15] <slangasek> hallyn: dpkg-maintscript-helper(1), "mv_conffile"
[21:16] <infinity> hallyn: Potentially both of those answers.
[21:16] <slangasek> hallyn: which can be automated using debhelper by creating a debian/qemu-system.maintscript file, containing a mv_conffile [...] line
[21:17] <infinity> slangasek: Will mv_conffile still do sane things if it's also being bounced between packages at the same time?
[21:17] <infinity> (Which is the case here, I believe)
[21:17] <slangasek> infinity: provided you include the "package" argument, I believe so
[21:18] <infinity> Which package would that be?  The old or the new?
[21:18] <hallyn> slangasek: thanks, looking at the manpage
[21:18] <hallyn> infinity: thanks much, have high hopes that it'll work after next build :)
[21:18] <infinity> hallyn: Well, fixing the versioning can't make it any worse off anyway. :P
[21:19] <infinity> hallyn: Also, dpkg --compare-versions is your friend.  Especially before you accidentally paint yourself into crazy corners you can't version out of.
[21:19] <infinity> (But once you do, it's also your partner in crime in trying to come up with evil hacks to make things even worse)
[21:20] <hallyn> infinity: that's the thing, i *did* use dpkg --compare-versions.  which makes me wonder what concoction i was drinking that day.
[21:21] <infinity> hallyn: Whatever it was, you should send me a thermos full.
[21:23] <infinity> hallyn: (Don't forget to fix all your replaces and breakseses while you're changing your version, since those ones will never sort sanely for the +noroms upgrade case)
[21:24] <hallyn> infinity: fix the << 1.2.0-z to be << 1.2.0.dfsg-1 right?
[21:24] <infinity> Aye.
[21:24] <hallyn> yup, that's one, now i'm just trying to figure out how to use dpkg-maintscript-helper
[21:24] <infinity> If there *is* a danger of a 1.2.0.1, you don't want to use that scheme, BTW.
[21:24] <infinity> Since alpha sorts higher than num.
[21:25] <hallyn> well, upstream has 1.3.0, so i sure hope debian won't decide to do a 1.2.0.1
[21:25] <infinity> You could also go German and have 1.2.0+zfsg-1 ;)
[21:26] <hallyn> :)
[21:27] <slangasek> 1.2.0+zfsg-1GmbH ?
[21:27] <bdrung> gladk: thanks for the sync requests.
[21:28] <bdrung> gladk: i guessed that the upload to experimental was due to the freeze. :)
[21:29] <bdrung> gladk: feel free to ping me to get packages synced (if you want to avoid filing sync requests)
[21:29] <gladk> bdrung: Ok, thanks!
[21:30] <bdrung> you're welcome
[21:30] <gladk> bdrung: it would be good to sync freecad, but it should be better tested before
[21:30] <gladk> bdrung: I will let you know
[21:31] <bdrung> okay
[21:31] <bdrung> the ubuntu diff is funny :)
[21:35] <gladk> I have requested a month ago a bug LP:1072053 to fix a couple of annoying bugs in paraview-package, which shipped in 12.04 LTS
[21:35] <gladk> but no reaction since
[21:35] <gladk> should it get "freeze-exception" first?
[21:36] <bdrung> gladk: you got no reaction, because ubuntu-sponsors is not subscribed and therefore it does not show up on http://reqorts.qa.ubuntu.com/reports/sponsoring/
[21:37] <bdrung> gladk: for stable release updates, please follow https://wiki.ubuntu.com/StableReleaseUpdates
[21:37] <gladk> bdrung: ok, thanks
[21:39] <bdrung> time to bake a cake
[21:49] <penguin42> wow - an sprintf into a parameter; no wonder it crashed       sprintf(client_server,"%s_%s_%s", client_server, servername, getportname(server_port) );
[21:54] <infinity> penguin42: What could possibly go wrong?
[21:55] <penguin42> infinity: Well.... according to the manpage of sprintf the standard explicitly disallows it (only as of C99 and Posix.1-2001!) and actually notes that somethings rely on it
[21:56]  * penguin42 doesn't understand how this code doesn't die on debian
[21:56] <infinity> I wouldn't have needed a manpage to point out that sprintf(foo, format, foo) might be a bad idea.
[21:56] <penguin42> infinity: Indeed, I thought I'd just better check though
[21:56] <penguin42> infinity: The fact that there is an explicit note about it in the man page and that it was only in C99 that it was explicitly disallowed is worrying
[21:57]  * penguin42 thinks this code is probably unsalvegable
[22:11] <penguin42> for ref that's bug 1026902 / debian bug 695312
[22:15] <infinity> penguin42: It could segv on Ubuntu but not Debian because we build with FORTIFY_SOURCE=1
[22:19] <Adri2000> is it possible to see why a package hasn't yet migrated from the proposed pocket to the release pocket? (in the current developement release)
[22:20] <ScottK> Adri2000: Yes.http://people.canonical.com/~ubuntu-archive/proposed-migration
[22:21] <ScottK> The britney output is not the easiest to parse, but the data is there.
[22:32] <Adri2000> ScottK: thanks. btw, just uploaded opencv. once it's built everywhere, I will upload an actionaz rebuild
[22:32] <ScottK> Adri2000: Thanks.
[23:28] <penguin42> infinity: I was more surprised that it managed to survive even on a system without fortify