[00:01] <Laney> under the "what of GHC in testing" heading
[00:01] <mathiaz> jtimberman: are you using a vm or a chroot to do your testing?
[00:02] <jtimberman> vm
[00:04] <mathiaz> jtimberman: what's the command line that is running chef-indexer?
[00:04] <mathiaz> jtimberman: I mean in the output of ps -ef
[00:04] <jtimberman> root      8509     1  0 17:04 ?        00:00:00 ruby /usr/bin/chef-indexer -d -c /etc/chef/indexer.rb
[00:07] <jtimberman> i'm installing the gems with dpkg though, not apt.
[00:13] <mathiaz> jtimberman: gems == .deb?
[00:13] <mathiaz> jtimberman: are you using a pristine vm for your tests?
[00:15] <jtimberman> mathiaz: yeah, i have a snapshot from right after installation with no ruby or anything else. i install the external chef dependencies via apt, then install the packages via dpkg.
[00:15] <jtimberman> though i'm fixing my local apt repo
[00:16] <mathiaz> jtimberman: hm - that may be the reason
[00:16] <mathiaz> jtimberman: let me check
[00:17] <mathiaz> jtimberman: are you changing the signal handler in chef-indexer?
[00:17] <jtimberman> mathiaz: what do you mean?
[00:18] <mathiaz> jtimberman: are you changing the way signals are handle in the chef-indexer code?
[00:19] <jtimberman> mathiaz: not sure, i didn't actualyl write the indexer
[00:33] <mathiaz> jtimberman: it's an issue between chef-indexer and the stompserver
[00:33] <jtimberman> mathiaz: oh?
[00:33] <mathiaz> jtimberman: it seems that the indexer stops responding to TERM signals
[00:34] <jtimberman> mathiaz: hmm: FATAL: SIGTERM received, stopping (when running purge on the package0
[00:34] <mathiaz> jtimberman: right - apparently SIGTERM is not always received
[00:34] <jtimberman> fun. :/
[00:36] <mathiaz> jtimberman: yeah - I don't know.
[00:37] <mathiaz> jtimberman: so you're unable to reproduce it?
[00:37] <jtimberman> mathiaz: so far, yeah. it exits cleanly for me every time i purge.
[00:37] <mathiaz> jtimberman: it may be a timing issue
[00:37] <mathiaz> jtimberman: related to my vm setup
[00:38] <jtimberman> mathiaz: does it happen for you every time?
[00:38] <mathiaz> jtimberman: yes.
[00:39] <mathiaz> jtimberman: how are you connectin to your vm? via ssh or local console?
[00:40] <jtimberman> mathiaz: VM host is a VMware server on gigabit ethernet downstairs.
[00:40] <jtimberman> and I ssh in.
[00:40] <mathiaz> jtimberman: and how do you get into the VM guest?
[00:41] <jtimberman> mathiaz: ssh
[00:41] <jtimberman> mathiaz: it has bridged networking through the host, so directly on the same subnet.
[00:41] <mathiaz> jtimberman: I though it may have been related to bug 407428
[00:42] <jtimberman> mathiaz: mmm, i'm running alpha3.. i don't think i've done an upgrade since i installed several days ago
[00:42] <mathiaz> jtimberman: yeah - you'd better upgrade
[00:44] <jtimberman> oh tasty, rsyslog 4.2.0 :)
[00:50] <jtimberman> mathiaz: using apt-get purge or dpkg --purge, the chef-indexer always stops cleanly for me.
[00:51] <jtimberman> mathiaz: when you purge, does it remove stompserver as well?
[00:51] <mathiaz> jtimberman: nope
[00:52] <pochu> any emesene users around?
[00:52] <pochu> if so, can somebody try 1.5 from unstable (or incoming) and if it works fine, request a sync?
[00:59] <jtimberman> mathiaz: so what do you think, I can't reproduce the behavior you're seeing.. is this "okay" for packaging? do we need a second MOTU to check as well?
[01:00] <mathiaz> jtimberman: a second MOTU advocation is needed anyway to get the pacakage uploaded.
[01:01] <jtimberman> any other MOTU around able to look at Chef? http://revu.ubuntuwire.com/p/chef
[01:02] <jtimberman> oh, i see you advocated a bit ago :)
[04:13] <binarymutant> does the python team have a launchpad page?
[04:14] <vorian> there is a pythonist group
[04:15] <binarymutant> is that this https://wiki.ubuntu.com/MOTU/Teams/Python ?
[04:29] <ScottK> No.  That one is obsolete.
[04:29] <ScottK> There are two Python teams in LP, ~pythonistas and ~pythoneers.
[04:30] <binarymutant> ah ty
[09:23] <lfaraone> james_w: (or anybody else), can you ACK bug 417174 for me?
[09:29] <Laney> lfaraone: is it urgent?
[09:36] <lfaraone> Laney: Not particularly, I'd just like to beat FF.
[09:37] <Laney> You have the request in already, so it will be fine
[09:52] <lfaraone> Hey, my main GPG key (which is in the SWOT) is a DSA 1024 key. Is that strong enough for the considerable future? (for use while packaging etc)
[09:55] <geser> I'd say yes (I've one myself). It was long the gpg default for new keys.
[09:56] <wgrant> A lot of people migrated to stronger RSA keys earlier this year.
[09:56] <wgrant> DSA keys will hopefully all go away eventually.
[09:57] <wgrant> (although mine is 1024D as well)
[09:58] <geser> I've already started a slow migration to a DSA2 key, but the most signing I still do with my DSA1 key
[10:08] <lfaraone> geser: DSA2?
[10:11] <geser> DSA1 is limited to a 1k DSA/2k ElGamal key, this was moved higher for DSA2 (3k DSA/4k ElGamal)
[10:59] <hyperair> is there a way to figure out which ppa a package came from? (if it's already installed)
[11:00] <c_korn> apt-cache policy packahe
[11:00] <c_korn> *package
[11:01] <c_korn> hm, wait. that does not show you the exact url
[11:01] <hyperair> yeah, that's the problem =\
[11:01] <hyperair> it only says ppa.launchpad.net
[11:01] <hyperair> the only way i can think of is apt-get install --print-uris
[11:01] <hyperair> but that's annoying. isn't there some easier way?
[11:02] <hyperair> besides grepping in /var/lib/apt or something
[11:07] <c_korn> apt-cache showpkg vlc | grep -A 5 'Versions:'
[11:07] <c_korn> well, it does not grab in the /var/lib/apt directly
[11:07] <c_korn> :)
[11:07] <c_korn> s/grab/grep/
[11:09] <geser> hyperair: can you pastebin the output from apt-cache policy $package? I don't have any PPA in use currently
[11:09] <c_korn> it only shows: 500 http://ppa.launchpad.net jaunty/main Packages
[11:10] <hyperair> geser: http://pastebin.com/f2d3fbde1
[11:10] <c_korn> but not the PPA itself acutally
[11:10] <hyperair> yeah, it would be nice if it showed the entire repository URL
[11:10] <wgrant> That's probably an apt bug now that PPAs are so widespread.
[11:10] <hyperair> mmhmm
[11:10] <geser> file a bug against apt
[11:10] <hyperair> yep
[11:10] <hyperair> and if launchpad gets debian PPA support, i would think it'd get even more widespread =D
[11:10] <wgrant> Indeed.
[11:11] <geser> I guess it wasn't assumed to have several repositories from the same host when this code was written in the past
[11:11] <hyperair> actually we would be able to work around the issue if we instead had something like.. <ppa-name>.<owner>.ppa.launchpad.net or something
[11:11] <hyperair> mmhmm
[11:20] <_ruben> doesnt work well with https tho
[11:22] <wgrant> And P3As have to use HTTPS.
[11:22] <wgrant> So fixing apt is required.
[11:33] <geser> do the deb lines for P3As also end in /ubuntu?
[11:34] <wgrant> geser: Yes. They're the same, but https://user:pass@private-ppa.launchpad.net rather than http://ppa.launchpad.net.
[12:20] <hyperair> p3as huh O_o
[12:50] <geser> Private PPAs
[12:50] <hyperair> yeah, i realized
[16:44] <RoAkSoAx> vorian, ping
[18:01] <montelEdwards> can someone help me with a pkg
[18:02] <montelEdwards> I need to edit the package dependices which are wrong
[18:04] <geser> which package and which dependency is wrong?
[18:05] <montelEdwards> geser, http://download.limewire.com/download/LimeWireLinux.deb
[18:05] <montelEdwards> limewire
[18:05] <montelEdwards> It wants the Java (non free) jre
[18:06] <montelEdwards> and it works fine with openjdk
[18:06]  * montelEdwards knows that because he ran it from source
[18:07] <montelEdwards> geser, I tried to edit it and rebuild it but i got dpkg-deb: failed in buffer_read(fd): copy info file `LimeWireLinux/DEBIAN/control': Is a directory
[18:07] <geser> hmm, and is the error message true?
[18:08] <montelEdwards> yesx
[18:08] <montelEdwards> isnt it suposed to be a dir?
[18:08] <geser> let me think, I edit .debs pretty rarely
[18:09] <montelEdwards> I got it and everything, I just need to know how to rebuild it
[18:10] <geser> control should be a simple textfile
[18:10] <geser> how did you extract the deb?
[18:11] <montelEdwards> file-roller
[18:11] <hyperair> debs are ar archives
[18:11] <hyperair> inside it you will find data.tar.gz and control.tar.gz
[18:11] <hyperair> open control.tar.gz, and change the stuff in the control text file
[18:11] <hyperair> the syntax should be pretty obvious
[18:12] <hyperair> then re-tar control.tar.gz, and pack it together with data.tar.gz into an ar archive, then rename it to something.deb
[18:12] <montelEdwards> hyperair, how do i compress .ar
[18:12] <hyperair> use file-roller
[18:12] <montelEdwards> it wont work
[18:13] <hyperair> it did for me
[18:13] <hyperair> i've done it before
[18:13] <hyperair> and what does "won't work" mean?
[18:13] <hyperair> exactly what fails?
[18:14] <geser> or "dpkg-deb -x Limewire.deb limewire; cd limewire; dpkg-deb -e ../Limewire.deb", edit DEBIAN/control, "cd ..; dpkg-deb -b limewire" to build the fixed deb
[18:15] <montelEdwards> hyperair, it just like pops up, and exits
[18:15] <montelEdwards> no archive
[18:15] <hyperair> ?
[18:16] <hyperair> use nautilus then
[18:16] <hyperair> highlight control.tar.gz and data.tar.gz then right click and compress
[18:17] <montelEdwards> oh nvm
[18:17] <montelEdwards> hyperair, i rmed the files in it
[18:17] <montelEdwards> so it was making a blank archive
[18:17]  * hyperair doesn't understand =.=
[18:18] <hyperair> anyway what geser said is a better way of doing it
[18:18] <montelEdwards> dpkg-deb: file `/home/montel/LimeWireLinux.deb' is not a debian binary archive
[18:18] <geser> montelEdwards: it this the downloaded file?
[18:19] <montelEdwards> yes
[18:19] <geser> because I tested this myself to give you the correct steps
[18:19] <montelEdwards> my modified
[18:19] <geser> use it on the unmodified
[18:37] <montelEdwards> FINALLY
[18:37] <montelEdwards> i got it
[18:37] <montelEdwards> thanks geser hyperair
[18:37] <hyperair> np
[18:37] <hyperair> congrats (you should have just used frostwire's deb, it's got at least correct dependencies)
[18:37] <hyperair> but at least you learnt something new this way ;)
[18:41] <montelEdwards> hyperair, oh, im going to try them
[18:41] <hyperair> =)
[18:41] <montelEdwards> i just like Limewire's UI
[18:41] <hyperair> frostwire's UI is almost a direct clone of limewire's
[18:41] <hyperair> unless you count colours
[18:41] <hyperair> frostwire's is mostly blue
[18:41] <hyperair> but themeable
[18:42] <hyperair> the frostwire guys should seriously just do something about their copyright header issues and let us package it already =\
[18:42] <montelEdwards> hyperair, Medibuntu,,,,
[18:42] <hyperair> i meant officially in the archives
[18:42] <montelEdwards> oh
[18:43] <montelEdwards>  and
[18:43] <hyperair> hmm it seems that emacs has a .deb editing mode, by the way
[18:43] <hyperair> heheh
[18:58] <montelEdwards> damn
[18:58] <montelEdwards> im going to use the source code
[18:59]  * montelEdwards thinks LimeWire works better with openjdk
[19:06] <montelEdwards> hyperair, that is the new UI http://i29.tinypic.com/6f441c.jpg
[19:15] <hyperair> montelEdwards: oho, there's a new UI eh? that's interesting.
[19:16] <hyperair> it does look good, yes
[19:16] <hyperair> it looks rather like itunes
[19:16] <hyperair> or songbird
[19:18] <montelEdwards> hyperair, yep
[19:18] <montelEdwards> 5.0
[19:18] <hyperair> cool
[19:18] <hyperair> i wonder if frostwire will follow suite
[19:18] <montelEdwards> probably.
[19:18] <hyperair> heheh
[19:41] <sebner> huhu norsetto :D
[19:42] <norsetto> huhu sebner
[21:35] <debfx> could a universe sponsor please have a look at bug #256419
[21:35] <debfx> the pidgin-plugin-pack should really be updated
[22:11] <mhagger> I am an upstream author of a Python package.  What should I do with manpages to make the package easy to turn into a DEB package?  (This is using distutils.)
[23:37] <stochastic> can anyone tell me why my uscan claims this watch file doesn't have a proper URL : http://sf.net/xjadeo/xjadeo-(.+)\.tar\.gz
[23:40] <directhex> sf uses a special built-in redirect facility which breaks about 1/3 of the time
[23:43] <stochastic> so is the watch file okay or should I redesign it around the breaking redirect?
[23:47] <directhex> up to you
[23:48] <directhex> here's a workaround if you want it: http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/
[23:50] <stochastic> directhex, you don't have a minute to do a revu of that package do you http://revu.ubuntuwire.com/p/xjadeo
[23:50] <directhex> sorry, no
[23:54] <bdrung_> stochastic: i recommend to not change your watchfile and wait for a fixed redirect.
[23:54] <stochastic> bdrung_, that's the route I took
[23:57] <stochastic> bdrung_, I see you're on the MOTU media team, are you able to revu packages (it's a multimedia package)?