[02:21] <smoser> slangasek, smb i'd appreciate your thoughts on my most recent comments in bug 898373 .
[02:21] <smoser> it seems that cloud-init actually could be causing the fsck race, but i'm not sure how to avoid it.
[04:43] <MrBusiness> Does anyone happen to have a high-level guide to understand what a GNU/Linux "service" is, and the attendant concerns for someone needing to write one?
[04:45] <mfisch> MrBusiness: that's a pretty broad question, what are you trying to do?
[04:45] <MrBusiness> Well, let me see if I can put it into words
[04:46] <MrBusiness> I've been assigned to convert some manner of program into a service. I see that much of what constitutes a service appears to be a set of commonly accepted scripting interfaces, as outlined in /etc/init.d/skeleton, at least assuming I have not already erred in my understanding.
[04:47] <MrBusiness> Now, that said, I also notice that in order for these things to work, the services usually write their PID to a file upon launching so that the appropriate PID can be interacted with during later service calls to that process.
[04:47] <mfisch> MrBusiness: hold on
[04:47] <MrBusiness> Which gives me cause to wonder: if I wanted to variations on the same binary running as separate services, does this imply that I would need some sort of advanced logic with which to distinguish them and their respective PID identification files?
[04:48] <mfisch> MrBusiness: so if I were writing a new service, I would use upstart, not the old sysv stuff
[04:48] <mfisch> MrBusiness: look in /etc/init for examples, and here:  http://upstart.ubuntu.com/
[04:48] <MrBusiness> Is upstart based on the same sort of thing that came out of RedHat, or is it specific to Ubuntu?
[04:49] <mfisch> MrBusiness: I do not know the origins, I do know that Ubuntu uses it
[04:49] <mfisch> MrBusiness: and so did webOS
[04:49] <geofft> If you're talking about old-style (init.d) services, you may be interested in start-stop-daemon, especially with --pidfile and --make-pidfile
[04:50] <MrBusiness> hmm, ok
[04:50] <MrBusiness> Well, that's helpful. At this point, I guess I need to figure out just what it is that I'll be interacting with.
[04:50] <mfisch> the last service I wrote watched a directory using inotify and responded to changes there
[04:50] <mfisch> there are dozens of ways to talk to your service of cours
[04:51] <MrBusiness> I see. That's somewhat less than reassuring, but so it goes.
[04:51] <geofft> upstart (Ubuntu), systemd (Red Hat), etc. are relatively similar at a high level -- you write a config file describing the service that init uses, instead of a shell script
[04:51] <geofft> and yes, the init.d style is just a shell script with conventions.
[04:52] <MrBusiness> Ah, ok. That's probably what I'm dealing with here then.
[04:52] <mfisch> MrBusiness: you said it's a program, so how do you communicate with it now?
[04:52] <MrBusiness> at the moment, the only methods of communicating with it are defining its startup parameters
[04:53] <MrBusiness> after that, it just sits around doing its business periodically
[04:54] <mfisch> MrBusiness: so it runs on a schedule?
[04:54] <MrBusiness> yes
[04:54] <RAOF> Does it perhaps then just want to be called periodically by cron, rather than being a daemon itself?
[04:55] <mfisch> RAOF: not a bad plan.
[04:55] <MrBusiness> No, because it was designed to run continuously. There are parts that run as cron jobs, but those parts are not being registered as services.
[04:55] <RAOF> Ok.
[04:56] <mfisch> MrBusiness: do you need to change those start-up parameters while the code is running now?
[04:56] <MrBusiness> Part of what these things do is watch directories, and I don't really have control over their requirements. I was told to make them into services, and so I am attempting, as best I can, to carry out that order, whether it ultimately comes to good or ill.
[04:56] <RAOF> MrBusiness: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html seems like a reasonable HOWTO for the nuts and bolts of converting something to a daemon.
[04:56] <MrBusiness> No, I don't need to change them. I just need to get them installed and running as proper services.
[04:56] <mfisch> MrBusiness: I wonder if all you need to do is make a simple upstart script and fire it up
[04:57] <RAOF> Yeah.  If they're already daemonising properly you should just be able to write a very simple upstart script.
[04:57] <MrBusiness> Might be. I'm working from some legacy code to do this. I haven't quite described what is, in my view, the really onerous aspect of the thing, but it's difficult for me to describe it.
[04:57] <MrBusiness> Let me see if I can explain it
[04:57] <mfisch> MrBusiness: my last service was a python script that I wanted running when the system started
[04:58] <mfisch> MrBusiness: I just put command-line args inside the upstart job, you could use a conf file or gsettings to change params too
[04:58] <MrBusiness> One common thing I see in most services is that typically they tend to refer to a daemon process, of which there is typically only a single instance executing on a given system.
[04:58] <MrBusiness> I don't think that is a reasonable assumption for the processes I am attempting to convert into services.
[04:59] <MrBusiness> In fact, I am certain that there may be multiple instances of these processes, each running to perform similar tasks, but on different locations
[04:59] <MrBusiness> and that each must be considered its own service
[05:00] <mfisch> MrBusiness: so you have upstart fire-up either N jobs or have a wrapper that reads a conf file and fires up N instances
[05:00] <StevenK> So, this sounds more like a deployment problem, rather than related to Ubuntu development ...
[05:00] <mfisch> MrBusiness: you can put actual shell scripts into upstart so you could read a conf file in there
[05:00] <MrBusiness> Perhaps it is. Should I be in some kind of #deployment channel?
[05:00] <RAOF> MrBusiness: Perhaps rather than talking about terminology (service, process, etc) we start talking about *behaviour*.  What do you need to change in their behaviour?  Do you need the ability to monitor them with “status $SERVICENAME”?  Do you need them to be started on boot?  Do you need them to be restarted when they crash?
[05:01] <mfisch> MrBusiness: upstart will restart crashed services, which is nice
[05:02] <MrBusiness> let me think for a minute
[05:02] <RAOF> #upstart might be a better channel for this, indeed.
[05:03] <mfisch> MrBusiness: may I suggest that if you truly have N processes watching a bunch of directories that you write a wrapper (python would be easy) to do all the watching (started by upstart) and fire up your program based on what directory changed?
[05:03] <mfisch> RAOF: agreed.  hopefully we gave him enough to consider
[05:05] <MrBusiness> mfisch, a nice idea, but unfortunately beyond my power to enact at this point
[05:05] <MrBusiness> I don't have sufficient control of the requirements. it sounds to me like I get to watch this thing blow up in my face. rather than spend anymore time on it, I think I'll just update my resume.
[05:06] <MrBusiness> Gotta know when to hold 'em, gotta know when to fold 'em.
[05:12] <RAOF> MrBusiness: I obviously don't have a good grasp of your requirements, but nothing so far sounds particularly difficult; drop by #upstart and I'm sure we can set you up with something.
[05:12] <MrBusiness> alrighty
[05:13] <MrBusiness> Only one thing about it though, is that I'm not even certain that I'll have upstart available to me. I may be rolling with the init.d methods, because that may be the only thing available on the target environment.
[05:17] <andersk> Depending on what you need, www.supervisord.org (‘supervisor’ package in Ubuntu) might be helpful.
[06:05] <pitti> Good morning
[07:46] <dholbach> good morning
[08:17] <tjaalton> do packages that have not passed the NEW queue need a FFE if they are not accepted before FF?
[08:21] <pitti> tjaalton: no, usually we count the upload date
[08:21] <tjaalton> pitti: ok, good
[08:21] <pitti> NEW processing seems to be a bit on the slow side these days
[08:21] <tjaalton> no wonder, everyone trying to squeeze things through ;)
[10:10] <dupondje> Who did the MoM pages again ? :)
[10:10] <dupondje> cjohnston: ?
[10:10] <dupondje> cjwatson :)
[10:16] <tumbleweed> dupondje: launchpad.net/merge-o-matic
[10:17] <dupondje> tumbleweed: https://merges.ubuntu.com/ is stuck it seems :)
[10:17] <dupondje> not updated since 10/02
[10:18] <cjwatson> SpamapS: yes, MoM is crashing at the moment; thanks for noting that, I'll take a look
[10:19] <tumbleweed> dupondje: ^ there you go, then :)
[10:20] <dupondje> indeed ;)
[10:20]  * cjwatson was going through scrollback ...
[10:20] <cjwatson> ValueError: process failed 2: dpkg-source -x gexiv2_0.3.1-1.dsc /srv/patches.ubuntu.com/unpacked/g/gexiv2/0.3.1-1
[10:22] <cjwatson> I think I'll just nuke that - the .orig checksum in Debian's .dsc is wrong, but there's a subsequent version which unpacks properly
[10:22] <cjwatson> it was in experimental anyway
[10:23] <cjwatson> will need to wait until the current run has finished though
[10:23] <tumbleweed> dak accepted a .dsc with an incorrect checksum?
[10:24] <cjwatson> it's dated a while back
[10:24] <cjwatson> actually I think what happened is that it was correct at the time, but it was removed from experimental and then a new version was uploaded later with a different orig ...
[10:25] <tumbleweed> yeah, looks likely
[10:25] <cjwatson> which dak should have caught in principle but evidently hadn't retained the information
[10:25]  * cjwatson pokes DktrKranz with a spoon
[10:25] <cjwatson> evil reusing of version numbers
[10:28] <DktrKranz> huh?
[10:31] <cjwatson> $ grep '^ .\{32\} .*orig' gexiv2_0.3.1-*.dsc
[10:31] <cjwatson> gexiv2_0.3.1-1.dsc: 50d15e0f84c799fccea9aa7c28fd971a 29525 gexiv2_0.3.1.orig.tar.gz
[10:31] <cjwatson> gexiv2_0.3.1-2.dsc: fc2a438af67af7c9f27bbe0c19b31c98 30155 gexiv2_0.3.1.orig.tar.gz
[10:32] <cjwatson> should've been 0.3.1+<something>, really (but too late now)
[10:42] <DktrKranz> hhm, right
[10:44] <cjwatson> so I now need to convince merges.ubuntu.com that it's never heard of 0.3.1-1 and that those aren't the droids it's looking for
[10:45] <dupondje> apt-get install alzheimer
[10:45] <dupondje> :)
[11:52] <apw> does debootstrap honour http_proxy or is there a trick to it ?
[11:53] <cjwatson> it should just honour it
[11:53] <cjwatson> I mean it just calls out to wget
[11:53] <cjwatson> it doesn't have any specific proxy code
[11:56] <apw> cjwatson, ahh thanks, seems there is a sudo zapping those variables ... sigh
[11:59] <pitti> apw: set the proxy system-wide in control-center -> network -> proxy
[12:00] <pitti> that'll write it into /etc/environment instead of just your local session gsettings
[12:06] <cjwatson> Anyone with some C++/Qt clue fancy making packagesearch build?  I've tried backporting the obvious patch (from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639076) from upstream svn but it still fails, and even after I fix up some silly missing-translation bits in upstream svn the current tip fails to build in different ways in both precise and unstable.
[12:06] <cjwatson> I'm on the verge of just removing the binaries from the archive (since they're keeping old libept1 in place) but thought maybe some Qty person might care.
[12:30] <pitti> Riddell: do you know whether/how I can supply extra cmake build options (-DWITH_FFMPEG=OFF) in a standard dh7 debian/rules?
[12:30] <nebuchadnezzar> hello
[12:31] <nebuchadnezzar> anyone to answers some questions about iso generation? there is nobody on #ubuntu-iso :-/
[12:32] <Riddell> pitti: you need to override dh_configure or whatever it is
[12:32] <pitti> /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm doesn't say something obvious
[12:32] <Riddell> override_dh_auto_configure: dh_auto_configure -Skde -- -DCMAKE_USE_RELATIVE_PATHS=ON
[12:32] <Riddell> pitti: something like that?
[12:32] <pitti> Riddell: nice, thanks! trying that
[12:33] <i8x4> Lost most my compiz key bindings with the latest upgrade; anyone else experience this?
[12:39] <nebuchadnezzar> I would like to use more than one repository in addition to the ubuntu one when generating a CD
[12:39] <pitti> Riddell: worked like a charm
[12:45] <Riddell> pitti: now you just need to persuade all the canonical and gnome developers to do the right thing and change to cmake :)
[12:46] <pitti> -ENOTENOUGHMAGIC :)
[12:49] <seb128> Riddell, it's not friday, no trolling! ;-)
[12:59] <Eren> is there a repository for infinality font patches, or should I get the source and compile it with these patches?
[13:58] <rbasak> I seem to have a package that FTBFS using fakeroot, but works under real root. I can pin down the cause further, but has anybody seen anything like this before? Any advice?
[14:04] <cjwatson> rbasak: not unheard of; can you narrow that down a bit?
[14:10] <rbasak> I think it might be a build-dep that provides an executable that segfaults unless it's root. Testing that hypothesis now.
[14:29] <m4n1sh> ev: there?
[14:29] <ev> m4n1sh: hi
[14:29] <m4n1sh> hello Evan
[14:30] <ev> how's it going?
[14:30] <m4n1sh> I am trying to integrate diagnostics in alm
[14:30] <m4n1sh> the thing is that there are two files
[14:30] <m4n1sh> one is about panel intergation
[14:30] <m4n1sh> but also contains lots of Panel plumbing code
[14:31] <m4n1sh> ev: since you have written the code, if you can quickly tell me which all thing is g-c-c specific
[14:31] <m4n1sh> sot that I can quickly integrate it. Need to get this release out by tomorrow.
[14:32] <ev> m4n1sh: preferences-panel.c contains the g-c-c bits. whoopsie_daisy_preferences_panel_init is the entry point.
[14:32] <m4n1sh> okay
[14:33] <m4n1sh> checking
[14:34] <m4n1sh> ev: under canonical contributor agreement?
[14:34] <ev> m4n1sh: that's a good question.
[14:34] <m4n1sh> if that codebase is under whoopsie then I think it can apply
[14:34] <m4n1sh> but if I take it and keep it under acitivity-log-manager repo
[14:35] <m4n1sh> then it should not apply
[14:35] <m4n1sh> not a lawyer, but I guess that can be the case
[14:36] <ev> just checking
[14:36] <m4n1sh> okay
[14:49] <ev> m4n1sh: I'm checking with the right authorities :). I wouldn't worry too much about getting it merged in today. The code already exists in the archive, and I think moving it from being its own page to being a GtkNotebook page is more of a UI freeze issue than a feature freeze one.
[14:50] <m4n1sh> yes
[14:50] <m4n1sh> even I think so
[14:50] <ev> Especially given that we may be blocked on this contributor agreement issue for a few days.
[14:50] <m4n1sh> can you confirm with the release team
[14:50] <m4n1sh> about whether it falls with UI freeze or feature freeze
[14:51] <m4n1sh> ev: even I feel it to be a UI freeze one, but if you can check out with anyone in release team, it would be great
[14:51] <ev> sure
[14:51] <m4n1sh> please update me once you have confirmed
[15:00] <m4n1sh> ev: I have a feeling that FF applies to this because whoopsie is not enabled by default
[15:00] <ev> m4n1sh: whoopsie will be enabled just as soon as I finish making the changes requested in its security review
[15:00] <m4n1sh> it is in main?
[15:00] <m4n1sh> MIR done?
[15:03] <ev> m4n1sh: there's a MIR, which will be approved once the changes requested by the security team are made (I'm in the midst of that now)
[15:03] <m4n1sh> great
[15:03] <m4n1sh> excellent
[15:03] <ev> once that's done, I just need to seed it and it will be running by default
[15:03] <m4n1sh> :)
[15:04] <ev> m4n1sh: cjwatson (of the release team) suggests it is not a feature freeze matter.
[15:04] <ev> so by all means, release what you have :)
[15:05] <cjwatson> not this particular part of it.
[15:05] <m4n1sh> release yesterday itself
[15:05] <m4n1sh> Didier uploaded it
[15:05] <m4n1sh> I uploaded it yesterday since I was not sure if I could complete this one
[15:05] <m4n1sh> cjwatson: thanks for clarifying
[15:27] <akgraner> cjwatson, I just updated my notebook  and got a libc6 error - now I have packages with umnet dependencies  - Do I follow the  running -f instructions or do I need to do something else?
[15:29] <cjwatson> akgraner: can I see the exact error messages
[15:29] <cjwatson> can't give advice without that
[15:30] <akgraner> cjwatson, sure one sec I'll get them to you - they are on a different machine than the one I am using for xchat.
[15:34] <arand> It looks as though someone on #ubuntu+1 has a similar issue?: "can anyone help me fix broken apt? E: Internal Error, No file name for libc6"
[15:38] <cjwatson> arand: well, once again, would need more details than that ...
[15:38] <cjwatson> release, architecture, whether multiarch is enabled, full transcript of upgrade attempt, ...
[15:40] <akgraner> cjwatson,  dropped it to you in a pm along with what I did when and the point at which I was advised to contact you.
[15:41] <arand> cjwatson: "I'm on P, amd64, with multiarch" which is the upgrade log file to look for?
[15:42] <arand> cjwatson: "term.log: http://paste.ubuntu.com/841833/"
[15:52] <cjwatson> arand: bizarre.  'sudo dpkg --configure -a' might help
[15:52] <cjwatson> Having trouble seeing why apt got the ordering wrong in the first instance there.
[15:52]  * cjwatson notes that there is nearly a day's gap between the first error there and the attempt that apparently led to this report
[15:53] <lamalex> cjwatson, yah definitely
[15:53] <lamalex> too busy to deal with apt most of the time
[15:54] <lamalex> so usually i just leave it broken until i need to fix it :P
[15:58] <lamalex> cjwatson, hey that seems to have fixed it
[15:59] <lamalex> that + apt-get -f install
[15:59] <cjwatson> ok
[15:59] <lamalex> thank you
[15:59] <cjwatson> sadly hard to work back to the cause at this point
[16:00] <cjwatson> next time, assuming you were using update-manager, 'ubuntu-bug update-manager' should attach a state tarball to the bug that would be enough to let us reconstruct the initial state
[16:00] <lamalex> nice
[16:00] <lamalex> thanks
[16:19] <scott-work> does anyone have a suggestion for a particular person who might be a good candidate to review the lowlatency kernel in REVU (http://revu.ubuntuwire.com/p/linux-lowlatency)?
[16:19] <scott-work> luke y has already advocated it, so we just need one more person
[16:21] <tumbleweed> can I have some list-moderation on ubuntu-devel-announce please?
[16:25] <cjwatson> tumbleweed: done
[16:26] <tumbleweed> thanks
[16:27] <dupondje> cjwatson: MoM is still broken?
[16:32] <cjwatson> dupondje: it's running
[16:32] <cjwatson> took a while because it had been down for a while
[16:33] <dupondje> cool :)
[17:05] <dupondje> mm cjwatson I note some errors in the MoM pages
[17:05] <dupondje> python-drizzle for example gives 1.0-2ubuntu1 as current version
[17:05] <dupondje> while 1.0-3 got uploaded weeks ago
[17:05] <dupondje> same for samba4
[17:21] <didrocks> apw: hey, around?
[17:22] <apw> didrocks, hi
[17:22] <jhunt> cjwatson: Hi - could I trouble you to bump the priority on the 2
[17:22] <jhunt> builds here: https://launchpad.net/~jamesodhunt/+archive/upstart-testing ?
[17:23] <didrocks> apw: I'm wonering if you know of any kernel issues which can be stated as "after a period of lot of writing on disk (even swapping maybe), the CPU usage is going crazy"
[17:23] <cjwatson> jhunt: I don't see any builds there right now?
[17:23] <apw> didrocks, is that continious writing?
[17:23] <didrocks> apw: no, the writting ended
[17:23] <didrocks> but yeah, I has some continious one
[17:24] <didrocks> right now, my CPU usage is between 60% and 80% on my 2 cores, and if I look at htop, the sum of what is >1% should be at 20% max
[17:24] <jhunt> cjwatson: sorry - wrong ppa. should be https://launchpad.net/~jamesodhunt/+archive/upstart-job-logging
[17:24] <didrocks> seems everytime I swapped, I get this
[17:24] <apw> didrocks, the only diskio and cpu usage issue i have heard of is a possible issue xfs when the cache gets full
[17:24] <apw> didrocks, otherwise no i am not seeing the same herre on anything
[17:24] <didrocks> seems that seb128 got something similar somethimes
[17:25] <cjwatson> jhunt: done
[17:25] <didrocks> apw: I have such a behavior once a day at least, which forces me to reboot, anyway I can ensre that the CPU usage comes from some kernel threads?
[17:25] <jhunt> cjwatson: thanks!
[17:25] <apw> didrocks, get the machine up to date, and if it is reproducible lets get a bug filed please with a good description of your reproduce by
[17:25] <apw> didrocks, and include w
[17:25] <stgraber> jhunt: I like that changelog!
[17:25] <apw> didrocks, and include a ps -ef with the bad processes listed please
[17:26] <didrocks> apw: well, I'm up to date and getting that for now some weeks :)
[17:27] <apw> didrocks, yep and we had a pile of stable updates in the last kernel which was just the last day or two, so i want to make sure its not already fixed by that
[17:27] <NoaHall> Any Jockey devs in here?
[17:27] <didrocks> apw: ok, let me check I have the latest and greatest
[17:46] <slangasek> smoser: ah; this cloud script that's looking inside disks certainly fits the bill
[17:47] <pitti> apw, ogasawara: I binNEWed the new kernel, finally built on armel; can you please upload -meta?
[17:47] <ogasawara> pitti: yep, will upload right now
[17:47] <pitti> ogasawara: cheers!
[17:55] <stgraber> slangasek: hey, I seem to remember you knowing a bit about lvm2 and udev ;) I upgraded two of my servers to Precise and noticed a "sh -c /sbin/lvm vgscan; /sbin/lvm vgchange -a y" and it's child "vgchange -a -y" apparently spawned by udev but never exitting as expected. It's not causing any problem on these machines though but looked weird.
[17:55] <stgraber> slangasek: a very quick LP search gave me bug 802626 as a potential candidate for that weirdness
[17:56] <slangasek> stgraber: yes, the bug is still outstanding; there's a proposed fix from hallyn that I haven't managed to find time to review yet
[18:04] <hallyn> stgraber: yeah, that one's annoying isn't it :)
[18:05] <stgraber> hallyn: well, in my case it's only annoying when running "ps aux" on my all new server ;) it doesn't actually prevent anything from starting or cause any other issue that I could see
[18:05] <hallyn> interesting
[18:06] <stgraber> I have 3 PVs and 3 VGs on that machine, 1 of them is on RAID1 and contains the root LV, the two others are currently empty (no LV at all)
[18:08] <stgraber> my other server has hardware RAID (HP) but also has 3 PVs (3 RAID volumes) and 3 VGs, though in this case, they all have LVs and are all used
[18:35] <micahg> barry: in case you haven't seen, sphinx has a bug fix in unstable as well as needs and MIR (or something done) for python-whoosh
[18:43] <m_3> akgraner: ping
[18:43] <akgraner> m_3 pong
[18:46] <beuno> barry, congrats!
[18:52] <broder> barry: congrats on the dmb election!
[18:56] <sladen> %rfs
[19:05] <barry> broder: thanks!
[19:53] <apw> who owns nm-applet, the below cannot be right
[19:53] <apw>  2942 apw       20   0 6815m 1.7g 3080 S    2 43.3  21:56.80 nm-applet
[19:55] <micahg> bug /930491
[19:55] <micahg> bug 930491
[19:55] <micahg> ah, bot is awol
[19:57] <seb128> apw, cyphermox
[19:57] <seb128> though I guess he could try to blame it on indicators,dx
[19:59] <cyphermox> apw: I'm aware of it, trying to track it down
[20:13] <ScottK> barry: Is it you or doko that's supposed to do the lucid update for dh_python2?
[20:23] <barry> ScottK: doko
[20:24] <ScottK> Sigh.  doko: Can we get this done?  It's really causing problems.
[20:54] <slangasek> smoser: would you by chance be willing to test the latest ppa upstart build, to confirm that the logging support works as intended in the various cloud configurations? https://launchpad.net/~jamesodhunt/+archive/upstart-job-logging
[21:00] <smoser> slangasek, i can look tomorrow. is there a doc on what i'm supposed to see ? is it writing to /var/log/upstart.log ?
[21:00] <YokoZar> slangasek: is migrating packages to multiarch something that requires a feature freeze exception or is it just a normal bug?
[21:16] <slangasek> YokoZar: FFe
[21:16] <slangasek> smoser: /var/log/upstart/, one logfile per job that outputs
[21:16] <slangasek> smoser: http://www.theorangenotebook.com/2012/02/call-for-testing-upstart-14.html
[21:35] <kklimonda> hey, I need a place to host a small file for transmission SRU - so called blocklist (a list of ip ranges that BT client does not allow connecting to and rejects connections from)
[21:36] <broder> kklimonda: what does modern transmission use if the project isn't hosting the file anymore?
[21:36] <broder> (and can the sru switch to doing that instead)
[21:37] <kklimonda> broder: they have changed UI providing a way to set custom url instead
[21:37] <apw> cyphermox, may also explain didrocks symptoms
[21:37] <broder> kklimonda: is there a default?
[21:37] <kklimonda> broder: no, it's set to example.com
[21:37] <kklimonda> or something like that
[21:37] <apw> cyphermox, mine is growing slowly but surely too:
[21:37] <apw>  2942 apw       20   0 7165m 1.7g 3116 S    2 45.6  23:09.04 nm-applet
[21:37] <broder> kklimonda: it sounds like it's not actually mandatory anymore. can we just disable the blocklist?
[21:38] <kklimonda> broder: but blocklists just don't work in 10.04
[21:38] <kklimonda> broder: there is no "initial" list so there is no way to use this feature anymore :)
[21:39] <kklimonda> (it has never been mandatory, but it's a very popular feature of BT clients and we got some reports of it not working)
[21:39] <broder> i see
[21:40] <infinity> kklimonda: I'm not sure why we'd need to host a file?  There doesn't need to be a default blocklist (and, in fact, there isn't...)
[21:41] <kklimonda> infinity: but in 10.04 there is no way to change the blocklist url
[21:41] <kklimonda> infinity: it's hardcoded to http://update.transmissionbt.com/level1 in code, and the url is gone :)
[21:41] <infinity> kklimonda: Which is unfortunate, but "oh well"?
[21:42] <infinity> kklimonda: If you know what was in that file, you could just ship a copy with the package on-disk, and point to that.
[21:42] <kklimonda> infinity: hmm, that may work
[21:42] <infinity> kklimonda: But, really, there will be a new LTS in a couple of months, and it seems remarkably unlikely that the intersection of "people who torrent", "people who care about blocklists" and "people who run old releases" is very large.
[21:47] <kklimonda> infinity: yeah, it's still a bug though and us not fixing it for package in main sucks a little
[22:41] <YokoZar> slangasek: cjwatson: I just read https://bugs.launchpad.net/ubuntu/+source/libidl/+bug/931388  and it's worrying me because I used depends: wine1.4:any in the new wine1.4 packages as part of multiarching.  Will I need to do the dummy-package-with arch:all workaround?
[22:42] <YokoZar> (relatedly, wine1.4 is still half in the queue because wine1.2 and wine1.3 aren't yet deleted from the archive)
[22:42] <slangasek> YokoZar: I don't know what workaround you're proposing, but you aren't meant to be using :any yet in depends
[22:42] <YokoZar> slangasek: the workaround is at the bottom of this page: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641614
[22:44] <slangasek> YokoZar: ah; ugly, but yes, that would do it
[23:09] <cjwatson> YokoZar,slangasek: as I said in the Debian bug, I haven't tested that workaround yet, and it's mostly instinct
[23:10] <cjwatson> YokoZar,slangasek: if that approach works, I think it might be worth documenting in MultiarchSpec for the time being; I forgot this problem myself when talking to TREllis about the libidl implementation
[23:10] <slangasek> yeah, I've only eyeballed it; I don't see any reason it wouldn't work
[23:10] <YokoZar> cjwatson: is the wine upgrade case different from the libidl case as wine already requires a new packagename?
[23:11] <cjwatson> YokoZar: that doesn't make any difference
[23:11] <YokoZar> cjwatson: slangasek: regardless, I'll have to test it anyway.
[23:11] <cjwatson> YokoZar: it's still entirely possible that lucid's apt will be called upon to parse it
[23:11] <cjwatson> or for that matter germinate
[23:15] <YokoZar> cjwatson: Are you implying Wine will be pulled in by germinate :D
[23:15] <cjwatson> I think it is dangerous to take approaches that are known to fail
[23:26] <hallyn> d'oh!  for the life of me i can't figure out why sometimes bzr seems bound when it shouldn't be
[23:29] <hallyn> (oh well, that forced me to not pussyfoot around for another month fearing to commit :)
[23:37] <superm1> TheMuso`: is the current plan alsa 1.0.25 for precise or sticking with 1.0.24?  wasn't really clear to me from blueprints