[00:00] <SpamapS> Its only going to affect people who have built against 0.8.2, and use the error enums, and then move their app directly to maverick without recompiling.
[00:00] <mathiaz> SpamapS: if they recompile on maverick it wouldn't be broken?
[00:00] <SpamapS> nope
[00:01] <SpamapS> It will be fine because maverick has 0.8.3
[00:01] <mathiaz> SpamapS: so IOW the only broken use case is: a 3rd party app built on lucid wouldn't work on maverick?
[00:01] <SpamapS> What won't be fine is if there's somebody mixing debian/backports.org/ubuntu packages and they end up depending on libdbi0 from squid (0.8.2) and then try to use it on ubuntu.
[00:01] <SpamapS> s/squid/squeeze/
[00:02] <SpamapS> right, app from lucid that uses the error enums will break on maverick
[00:02] <SpamapS> or likewise, an app compiled on maverick that uses the enum will break on lucid
[00:03] <SpamapS> its just a confusing situation
[00:03] <SpamapS> The fear I have is that the breakage will be *really* subtle
[00:03] <mathiaz> SpamapS: right - so I lean towards not updating the libdbi package in maverick and add a release note
[00:04] <SpamapS> its not a missing symbol, its a missing constant value.
[00:04] <SpamapS> so like, your app from maverick goes  if error == XYZ ...   you'll never match that value if you install the package on lucid
[00:05] <mathiaz> SpamapS: ok - let's explore the other solution.
[00:05] <mathiaz> SpamapS: all the packages required to be rebuilt are ready?
[00:05] <mathiaz> SpamapS: how did you rebuilt them?
[00:05] <SpamapS> ppa
[00:05] <SpamapS> ran test suites where available too
[00:05] <mathiaz> SpamapS: ready == the source has been modify to use libdbi-dev instead of libdbi0-dev?
[00:05] <SpamapS> yeah
[00:06] <SpamapS> I held off pushing for merge proposals until we decided what to do in maverick.
[00:06] <mathiaz> SpamapS: do you have the PPA url?
[00:07] <SpamapS> hrm.. I must have deleted the packages.. it was in https://edge.launchpad.net/~clint-fewbar/+archive/fixes/+packages
[00:07] <SpamapS> rrdtool is still there though
[00:08] <SpamapS> mathiaz: I wasn't very scientific about it I guess. ;)
[00:08] <mathiaz> SpamapS: do you still have the source packages somewhere?
[00:09] <mathiaz> SpamapS: IIRC it's possible to copy src package from PPA to the primary ubuntu archive
[00:09] <SpamapS> mathiaz: what about having a new source package called libdbi084 that adds libdbi-dev to the archive...
[00:09] <mathiaz> SpamapS: hm - that's too complicated
[00:09] <mathiaz> SpamapS: if you still have all the source packages, I could sponsor them easily
[00:10] <SpamapS> mathiaz: I always tack on ~ppa so that wouldn't work. but let me find the dir with all of them
[00:10] <SpamapS> mathiaz: only rrdtool is in main
[00:10] <mathiaz> SpamapS: given that you've already tried to the rebuild and tested them in the PPA that's a good thing
[00:10] <SpamapS> though libdbi-drivers is supposed to be in main too and hasn't seeded yet
[00:10] <mathiaz> SpamapS: has the MIR been approved?
[00:11] <SpamapS> mathiaz: long ago.. just never seeded
[00:11] <mathiaz> SpamapS: ok - I can do that too - is there a bzr branch to sponsor somewhere?
[00:11] <SpamapS> mathiaz: its not Depended or Recommended by any main packages.. sort of a weird seed because libdbi is useless without them.
[00:11] <SpamapS> why yes there is..
[00:12] <SpamapS> https://code.edge.launchpad.net/~clint-fewbar/ubuntu-seeds/platform.maverick-add-libdbi-drivers
[00:12] <SpamapS> I can propose for merging if need be
[00:13] <mathiaz> SpamapS: I'll merge your branch
[00:18] <SpamapS> mathiaz: if you look, there are already some branches linked to the bug report for the dependent packages
[00:25] <SpamapS> mathiaz: crap.. I'm at starbucks and they seem to be blocking port 21. weird.
[00:25] <mathiaz> SpamapS: so my proposal is to leave things as it is for maverick on libdbi
[00:26] <mathiaz> SpamapS: and may be a release note
[00:26] <mathiaz> SpamapS: I'm merging the libdbi-driver seed change
[00:26] <SpamapS> mathiaz: I think thats 100% reasonable
[00:26] <SpamapS> mathiaz: I think a release note in the "known issues" is definitely a good idea.
[00:27] <SpamapS> mathiaz: lets leave it at that. Do I need to contact somebody about the release note?
[00:28] <mathiaz> SpamapS: I'll open a task against the release-note project
[00:28] <mathiaz> SpamapS: I'd suggest to update the description of the bug with a section outlining the release note to be added
[00:28] <psusi> final freeze is in effect isn't it?
[00:28] <mathiaz> SpamapS: once the release notes are being prepared the release manager will just need to copy'n paste the note for the bug
[00:28] <SpamapS> soon
[00:30]  * psusi hopes he can get this fix applied in time so mav doesn't ship with broken dmraid support
[00:31] <SpamapS> mathiaz: ok, I'm satisfied that we've exhausted all avenues. ;)
[00:31] <SpamapS> mathiaz: and actually I prefer this route, as it means we can just pursue this in Debian directly and get rid of any delta.
[00:31]  * mathiaz nods
[00:32] <mathiaz> SpamapS: we should revisit that for natyy
[00:32] <mathiaz> SpamapS: natty
[00:32] <mathiaz> SpamapS: given that squeeze is frozen it may take some time until Debian is released
[00:32] <mathiaz> SpamapS: so if it's really important we may wanna schedule to do it in natty
[00:33] <mathiaz> SpamapS: doing the work in Debian is also a very good option - there is not guarantee that it will be done in time for natty though
[00:33] <SpamapS> mathiaz: *ugh*
[00:34] <TheMuso> psusi: Let me know if you need a sponsor.
[00:34] <SpamapS> We can at least get it into experimental
[00:34] <SpamapS> so the devs can just bump those packages to unstable whenever they're comfortable.
[00:35] <mathiaz> SpamapS: right - that's a good option.
[00:35] <SpamapS> mathiaz: thanks for working through it with me. I'm sure we'll get it right for natty. :)  Should we remove the server-mrs tag?
[00:35] <mathiaz> SpamapS: I'm doing something similar with the puppet package
[00:36] <mathiaz> SpamapS: where the version in maverick is the actually the one from experimental
[00:36] <psusi> TheMuso, actually I was noticing you do work on... wait, I might be thinking dmraid?  grub needs a patch to fix its brokeness for dmraid that developed during mav cycle... finished building now with debian's patch, going to boot live usb, install new package, and test installing now
[00:36] <mathiaz> SpamapS: yes - I've also opened a task against the ubuntu-release-notes project
[00:36] <SpamapS> mathiaz: I think when debian is in freeze, thats going to be a common thing.
[00:36] <TheMuso> psusi: ok
[00:37] <JanC> psusi: is that related to the naming of dmraid devices?
[00:37] <psusi> TheMuso, but so far, looks like grub-pc is returning the correct results... and this patch also fixes those ANNOYING memory leak warnings ;)
[00:37] <psusi> JanC, yes...
[00:38] <psusi> it was looking for a device name containing mapper/ but the name gets canonicalized to dm-x
[00:38] <TheMuso> lovely
[00:38] <psusi> going to go test a new clean install using it now... bbiab
[00:39] <mathiaz> SpamapS: https://code.edge.launchpad.net/~clint-fewbar/ubuntu-seeds/platform.maverick-add-libdbi-drivers
[00:39] <mathiaz> SpamapS: ^^ I've merged the diff
[00:39] <mathiaz> SpamapS: so you can update your branch accordingly.
[00:40] <SpamapS> mathiaz: :-D cool
[00:40] <SpamapS> mathiaz: I've been trying to keep all my branches marked accurately... they stack up quick. ;)
[00:41] <mathiaz> SpamapS: yop - OTOH that gives you a lot of LP karma :)
[00:42] <SpamapS> mathiaz: I should throw a party when I get to 10,000
[00:43] <SpamapS> OK I have to run..
[00:43] <SpamapS> mathiaz: thanks again, ttyl!
[00:43] <mathiaz> SpamapS: sure!
[01:12] <psusi> damn.... grub-install works fine now, but for some reason ubiquity says it fails.... updating daily iso and retrying
[01:12] <psusi> it also says it is running it on /dev/sda the first time despite the fact that I told it to use the raid
[01:15] <TheMuso> Yay dmraid. I am glad I don't deal with that garbage any more. :p
[01:16] <psusi> heh, I'm using lvm to hold various install volumes that are split and I sometimes migrate across the dmraid disks, the ssd, and the 1.5 tb monster drive now ;)
[01:21] <psusi> btw, has anyone figured out how to deal with the very annoying massive slow down of dpkg due to ext4 being retarded issue yet?
[01:22] <TheMuso> Probably, I haven't investigated personally.
[01:45] <psusi> alright, it works... once I installed the updated grub package both on the livecd and on the target during the install
[01:45] <psusi> though ubiquity still claims it is installing grub to sda when it isn't
[01:51] <TheMuso> interesting.
[01:52] <psusi> so... what do I need to do now to get bug #634840 sponsored? ;)
[01:53] <TheMuso> Ah if the bug is in grub2, then I feel a little less comfortable in touching the grub2 packaging...
[01:53] <psusi> k... I'll have to poke cjwatson then
[01:53] <TheMuso> I also dare say that that will be able to get in post freeze.
[01:53] <psusi> do I need to do anything with the bug report?  like assign it to him?  or subscribe the release team or anything?
[01:54] <TheMuso> Even going by the one line description.
[01:54] <TheMuso> I'd have to read the docs to be sure, so no idea sorry.
[01:54]  * TheMuso has done it before in previous releases, but can't remember.
[01:54] <TheMuso> Probably a procedure similar to feature freeze exceptions.
[01:55] <psusi> that bloody memory leak message has been in there since lucid was released hasn't it?  bloody annoying thing... nice that this patch fixes that too
[01:56] <psusi> hrm... what now?  ureadahead?  e2defrag?  hrm...
[02:08] <psusi> cjwatson, when you wake up, take a look at bug #634840.  Patch attached from debian, tested well for me, fixes dmraid issue, as well as the annoying memory leak that has been there since lucid
[02:52] <TheMuso> s/c
[04:05] <josh_> This room is out of hand.
[05:05] <crimsun_> TheMuso: are you also merging in the latest stable-queue bits from pulse for upload?
[05:05] <TheMuso> crimsun_: took care of them yesterday when I uploaded pulse.
[05:05] <crimsun_> TheMuso: great!  thanks
[05:05] <TheMuso> np
[07:56] <Wubbbi> Hey guys. I found a strange bug. I use a netbook with broadcom Wifi and it realy works good. But now the problem. When I'm in Batterie mode ( even if the batterie is very very full ) my Wifi speed is like 3,4kb/s ... it takes 5 minutes to load google.com. In Lucid I dont have any problems. Well when I put in my Charger, the Wifi connection speeds up to normal speed. I dont have to reboot, no reconnect. I just put it in and its fast as
[07:56] <Wubbbi> normal. When I put it out again, the connection slows down. Can you guys take a look on it? I even can give you more information!
[08:04] <pitti> Good morning
[08:28] <tkamppeter> pitti, morning.
[08:29] <smb> pitti, Morning. I hate to ask but could we at least move the kernel stuff in Karmic-proposed into updates, even though the four reports also got no verification after 21 days?
[08:29] <pitti> hello tkamppeter
[08:29] <pitti> smb: hm, I'd like to see at least one report that it actually works
[08:30] <smb> *sigh* yeah
[08:30]  * smb hates those lazy buggers
[08:31] <tkamppeter> pitti, I got everything into Maverick except the auto-download for the Epson drivers, but there it seems that I have to tell Epson that I asked the Ubuntu developers for including it but there was not enough man power to implement it.
[08:33] <pitti> tkamppeter: right, unfortunately :/
[08:33] <pitti> tkamppeter: after next UDS I'll be back and can spend some time on that
[08:34] <tkamppeter> pitti, should we leave it as a bug report/feature request or should I create a blueprint/UDS session with apt and seurity people invited?
[08:35] <pitti> tkamppeter: from my POV the bug is fine; I don't think there's need for further discussion, it's a SMOP now
[08:35] <tkamppeter> SMOP?
[08:35] <pitti> but if you prefer a blueprint for tracking, that's fine
[08:35] <pitti> tkamppeter: "simple matter of programming"
[08:35] <tkamppeter> pitti, OK. So no blueprint.
[08:36] <tkamppeter> pitti, I think so, too. We have done all agreements with our security people, the LF, and the manufacturers, and the server side is completely implemented.
[08:37] <tkamppeter> Tpitti, the thing was only that I do not have the knowledge to implement the client side and the person(s) with the knowledge did not have the time.
[08:38] <tkamppeter> s/Tpitti/pitt/ ^^
[08:40] <tkamppeter> pitti, I was so much behind this Epson thingy because Epson people were pressurizing, and I also wanted to turn a project into live I worked a longer time on, and I hoped by showing off the Epson auto-download in Maverick, the other manufacturers and also the other distros will quickly follow.
[08:40] <pitti> mvo: can you please upload the fix for bug 633967 to maverick ASAP? this blocks the lucid SRU
[08:41] <pitti> tkamppeter: don't worry, the next Ubuntu release will come :)
[08:42] <pitti> kirkland: can you please upload the fix for bug 590929  to maverick, so that the lucid SRU can go to -updates?
[08:43] <tkamppeter> pitti, at least I could cater for Ricoh: PPD selection sensitive to presence of PostScript add-on installed in printer and much faster PPD search and package download/installation.
[08:48] <mvo> pitti: hm, that should be in already, let me check
[08:50] <mvo> pitti: not sure why the bug was not auto-closed
[08:50] <pitti> mvo: LP doesn't currently auto-close bugs
[08:50] <pitti> if it was fixed only recently
[08:57] <mvo> pitti: aha, ok. thanks
[08:58] <smb> pitti, did you reject the hardy upload because of the events from yesterday or another reason. iow, should I bother to prepare it to re-upload later on?
[08:58] <pitti> smb: I thought we agreed to wrap this into another update, but that uploading it by its own isn't worth it? also, I thought it's superseded by the security update now anyway
[09:00] <smb> pitti, second is true. first maybe we did miss each other. I'd rather do that on its own on hardy as there are not really much normal things coming along there.
[09:01] <pitti> smb: so just commit it, and we'll wait with the upload until something more urgent pops up?
[09:03] <smb> pitti, That might be never. Because urgent things will likely be security and those wont take that. And then I end up pushing around a commit for the remaining lifetime of hardy and that is just a waste of effort.
[09:03] <pitti> smb: then my gut feeling is to just forget about it; if it hasn't hurt anyone in over two years, then it's not a biggie now
[09:08] <smb> pitti, Alright then. I rather not bother about that then
[10:15] <pitti> YokoZar: hey, how are you?
[10:15] <pitti> YokoZar: question for you in bug 606509
[10:15] <YokoZar> pitti: heya
[10:19] <pitti> smb: is the linux-mvl-dove upload (lucid) still current, with yesterday's security update?
[10:20] <smb> pitti, It basically is all moot atm
[10:20] <pitti> smb: ok, rejecting then
[10:20] <smb> ack
[10:23] <YokoZar> pitti: per my comment on 606509 I'll get to work on a new gnome-exe-thumbnailer for Lucid
[10:24] <pitti> YokoZar: in other words, you want to overwrite the current SRU and not publish it?
[10:25] <YokoZar> pitti: no, hold it for now
[10:25] <pitti> ack
[10:25] <YokoZar> pitti: and I'll upload a new gnome-exe-thumbnailer and we release them together
[10:25] <YokoZar> pitti: then the minor bugfix can follow
[10:25] <pitti> YokoZar: no, I think we misunderstand
[10:25] <pitti> YokoZar: I'll hold the current upload in the unapproved queue
[10:26] <pitti> YokoZar: but I meant the pacakge which is already in lucid-proposed and got some testing
[10:26] <pitti> i. e.  1.2-0ubuntu1~lucid3
[10:26] <YokoZar> Yes hold off on moving that to -updates
[10:26] <pitti> ok
[10:26] <YokoZar> wait for it to go to -updates at the same time as a new gnome-exe-thumbnailer that isn't ugly
[10:26] <YokoZar> the reason is if they install the old one it'll cache some ugly thumbnails that won't change
[10:29] <pitti> ok; but then I'd still prefer ~lucid4 to be on top of ~lucid3, i. e. get its own changelog
[10:29] <pitti> so that we don't invalidate all the testing that went into ~lucid3
[10:35] <vish> could someone upload this for maverick? lp:human-theme fixes a small bug Bug #553393 ..
[10:35] <vish> obviously someone still uses human theme ;p  .. they came to -artwork asking for a fix ;)
[10:36] <vish> human theme is still in main.. maybe it should be moved to universe?
[10:47] <jibel> pitti, I think that you can publish gzip from lucid-proposed to -updates. It was verified 4 weeks ago but the list of pending SRUs fails to report the status.
[10:48] <jibel> pitti, bug 524366
[10:48] <pitti> jibel: ah, the syntax is wrong in https://edge.launchpad.net/ubuntu/lucid/+source/gzip/1.3.12-9ubuntu1.1
[10:48] <pitti> jibel: thanks
[11:08] <cnd> pitti, do you know where didrocks or seb128 are?
[11:09] <pitti> cnd: no, I don't; I think didrocks mentioned something about holidays until Friday
[11:09] <cnd> ok
[11:10] <mvo> seb is on vacation as well
[11:11] <cnd> mvo, thanks
[12:15] <ogra> hmm, so whats up with samba today
[12:40] <pitti> l
[13:40] <cnd> pitti, would adding an apport hook require an FFE?
[13:45] <shadeslayer> jcastro: thanks for the sponsorship... thanks to canonical as well :D
[13:45] <shadeslayer> could you tell me who else is coming from the Kubuntu team btw?
[13:59] <pitti> cnd: no, those are fine
[14:00] <cnd> pitti, ok, thanks!
[14:04] <jjohansen> cjwatson: is it you I bug about a grub2 issue?
[14:04] <cjwatson> yes
[14:05] <jjohansen> cjwatson: okay, I have a multipath bug I am looking at but grub-probe is failing with error no mapping exists for X-part1
[14:05] <jjohansen> where X is the multipath
[14:06] <jjohansen> that exists in /dev/mapper/
[14:06] <cjwatson> run it with -vvv and send me the output, together with ls -l of the relevant device nodes and the contents of /boot/grub/device.map (if any)
[14:06] <jjohansen> cjwatson: okay, thanks
[14:07] <ogra> can a buildd admin please bump https://edge.launchpad.net/ubuntu/+source/samba/2:3.5.4~dfsg-1ubuntu6/+build/1962200 and https://edge.launchpad.net/ubuntu/+source/ubiquity/2.3.19/+build/1962841 to very high ?
[14:08] <pitti> ogra: done
[14:08] <ogra> thanks
[14:09] <ogra> pitti, if you want amd64 to build properly again i'd suggest doing that for samba on amd64 too
[14:09] <pitti> ogra: it's already built on amd64
[14:09] <ogra> oh, it was powerpc ... sorry
[14:10] <pitti> bumped
[14:10] <ogra> i just heard several people complain about it not being upgradeble this morning ... and amd64 handt built then
[14:14] <ogra> bah, sigh, why is the armel queue so full
[14:14] <ogra> pitti, can i get  https://edge.launchpad.net/ubuntu/+source/ubuntuone-client/1.4.1-0ubuntu1/+build/1961868 bumped too ? (last one, promised)
[14:15] <pitti> ogra: nudged
[14:15] <pitti> ogra: well, yesterday we had a gazillion "OMGfreeze" uploads :)
[14:16] <ogra> pitti, yes, me too and i'd love to test them to find remaining bugs :=
[14:16] <ogra> :)
[14:16] <ogra> but that requires an image
[14:17]  * ogra would like to have separate buildds for proposed/security on arm ... 
[14:23] <chrisccoulson> pitti - well, i had to do a few OMGregression uploads yesterday ;)
[14:23] <chrisccoulson> that happened to coincide with all the OMGfreeze uploads
[14:48] <psusi> cjwatson: hey there, did you get my message from last night?
[14:49] <cjwatson> psusi: yes, I followed up to the bug, it's on my to-do list now.  I want to get it upstream
[14:49] <cjwatson> psusi: upstream's code freeze for 1.99 is in a few days and it would be good to get this sorted out there
[14:49] <cjwatson> psusi: but I want to spend a bit of time thinking about it and reconciling it with other patches people have sent to achieve similar goals, rather than going straight ahead with it
[14:49] <psusi> cool... but either way it's going to make it in maverick?
[14:49] <cjwatson> yes
[14:50] <cjwatson> I certainly don't want to release with broken dmraid support, as that's a recipe for lots of confusing bugs
[14:50] <psusi> ahh, ok... I had actually debugged the problem to that same area of code myself before I found that patch from debian... looked good to me and tested well
[14:50] <psusi> indeed
[14:51] <cjwatson> well, just to be clear, it's a bug report from a Debian contributor rather than a patch that's been applied to Debian
[14:51] <cjwatson> I'd want to fix it in Debian too
[14:51] <psusi> ahh
[14:55] <mvo> ogra: what was that samba issue you taked about earlier? hang in configure?
[14:56] <ogra> mvo, arch any vs arch all and full build queue
[14:57] <ogra> mvo, since arch all is built on x86 thats usually ahead so we get uninstallability
[14:58] <mvo> ogra: aha, ok. there is another samba releated issue that I was wondering about
[14:58] <ogra> ah, no, it was only installability issues during image build due to the above
[15:09] <ogra> StevenK, still awake ?
[15:12] <kirkland> pitti: fix is already in maverick
[15:13] <kirkland> pitti: i updated the bug status, but its noted in the sru justification
[15:13] <pitti> kirkland: ah, thanks
[15:20] <ogra> al-maisan, hey, mind letting linux-ti-omap4 our of NEW ?
[15:20] <al-maisan> ogasawara: sure, please give me a 10 minutes or so.
[15:21] <al-maisan> I am just finishing something up..
[15:21] <cjwatson> I can do it if you like
[15:21] <al-maisan> cjohnston: that would be great
[15:21] <cjwatson> though I see it's al-maisan's archive day
[15:21] <cjwatson> but anyway :)
[15:21] <al-maisan> if you don't get to it, I will do so in 10 minutes.
[15:22] <ogra> al-maisan, lol, you messed up all tab completion that was possible the the last lines :)
[15:22] <al-maisan> ouch :)
[15:22] <al-maisan> cjohnston: sorry
[15:22] <al-maisan> .. and, also sorry to ogasawara :)
[15:23] <ogra> she is used to it ... i'll claim back stolen pings in beer at uds :)
[15:24] <cjwatson> ogra,al-maisan: done
[15:24] <cjwatson> I think cjohnston must be used to it by now as well
[15:24] <al-maisan> thank you!
[15:24] <ogra> TA
[15:55] <mathiaz> cr3: o/
[15:56] <mathiaz> cr3: re checkbox 0.10.3 - I forgot to update the branch before I uploaded the package
[15:56] <mathiaz> cr3: could you prepare a 0.10.4 with the correct po file?
[15:58] <cr3> mathiaz: if this could wait until monday, I could do even better and fix a bug that's been affecting the translators team
[15:58] <mathiaz> cr3: well - final freeze is in less than 2 hours
[15:58] <mathiaz> cr3: is it release critical?
[16:02] <cr3> mathiaz: I think it would qualify as release critical, let me ask dpm
[16:02] <cr3> dpm: hey dude, do you think the bug in Checkbox affecting translations of questions to be release critical?
[16:02] <mathiaz> cr3: I'd ask the release manager as well
[16:03] <hallyn> ttx: proposed a fix for bug 488285.  probably too late, but...
[16:03] <mathiaz> cr3: the release team is making the final call
[16:04] <cr3> skaet: would you consider this bug release critical and be acceptable for an exception if fixed next week: https://bugs.edge.launchpad.net/ubuntu/+source/checkbox/+bug/514401
[16:04] <dpm> cr3, mathiaz, perhaps you guys can bring it up tomorrow in the release team meeting. For me personally, it would be important that checkbox could be used in any language
[16:06] <cr3> dpm: agreed
[16:06] <mathiaz> cr3: IIUC the most important bug has been fixed in 0.10.3?
[16:06] <cr3> mathiaz: yes
[16:07] <mathiaz> cr3: the remaining part is an updated po file that wouldn't be used for now unless another bug is fixed?
[16:07] <cr3> mathiaz: yes, so lets wait until we get a verdict tomorrow
[16:07] <skaet> cr3,  lets discuss tomorrow.
[16:08] <mathiaz> cr3: ok.
[16:09] <cr3> skaet, mathiaz: thanks folks!
[16:12] <mathiaz> ttx: so re samba bug - new bugs are still pouring in
[16:12] <mathiaz> ttx: should the package be blocked?
[16:13] <ttx> mathiaz: not sure, it's a development release after all -- ask the release team, I'm on a call right now
[16:14] <mathiaz> skaet: robbiew: cjwatson: slangasek: bug 639768 - samba fails to upgrade on maverick
[16:15] <mathiaz> bugs are pouring in LP - is it worth blocking the package on the mirrors?
[16:15] <cjwatson> I don't like doing that in development releases - can we just get it fixed ASAP?
[16:16] <mathiaz> cjwatson: I've started the investigation
[16:16] <mathiaz> cjwatson: in the mean time we can just mark the bugs duplicated
[16:16] <robbiew> mathiaz: yeah...I hit that last night
[16:17] <robbiew> I just killed the upload, dpkg --configure -a, and did another dist-upgrade
[16:17] <robbiew> it doesn't lock up the system or anything
[16:17] <mathiaz> robbiew: hm
[16:17] <mvo> it seems like ists enough to kill the "start smbd" process
[16:17] <mvo> I helped some people with that problem last night and today
[16:18] <mathiaz> robbiew: I've uploaded a new version of samba - but I don't see how it could produce that
[16:18] <mathiaz> mvo: right - so start smbd is blocking
[16:18] <mathiaz> robbiew: was your network down?
[16:19] <robbiew> nope
[16:19] <robbiew> I don't even use samba
[16:19] <mathiaz> looking at the smbd upstart job: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/samba/maverick/annotate/head%3A/debian/samba.smbd.upstart
[16:20] <mathiaz> line 4: start on local-filesystems
[16:20] <mathiaz> would this be the reason why start smbd blocks on package upgrade?
[16:21] <soren> mathiaz: I'd say no. that just specifies what will /automatically/ start samba. On upgrades, it would get explicitly restarted.
[16:22] <mathiaz> robbiew: do you have logs in /var/log/samba/ ?
[16:22] <mathiaz> robbiew: something like log.smbd?
[16:22] <mathiaz> robbiew: it may give a clue why "start smbd" was blocked
[16:22] <robbiew> let me check
[16:23] <soren> mathiaz: Do we know that that is what is blocked?
[16:23] <mathiaz> soren: I think so - see mvo comment above
[16:23] <soren> \O/ it hangs for me on install.
[16:23]  * soren investigates
[16:23] <mathiaz> soren: 11:17 < mvo> it seems like ists enough to kill the "start smbd" process
[16:24] <cjwatson> there was that recent change to cups
[16:24] <robbiew> yeah...I think that's related
[16:24] <cjwatson> which made it 'start on starting smbd' or similar, I believe
[16:24] <soren> Ah, so it's cups, maybe?
[16:24] <cjwatson> grr
[16:24] <robbiew> mathiaz: I'll attach my log.smbd file
[16:25] <cjwatson> misuse of 'and' in a way that's known to break upstart
[16:25] <cjwatson> ++start on ((starting smbd or filesystem)
[16:25] <cjwatson> ++          and started dbus
[16:25] <cjwatson> ++          and stopped udevtrigger)
[16:25] <robbiew> has CUPS related errors
[16:25] <cjwatson> that means that when 'starting smbd' arrived, it will wait for dbus to start and udevtrigger to stop (since those edge events have long since come and gone at system boot)
[16:25] <cjwatson> pitti: ^-
[16:25] <cjwatson> started and stopped are *not states*
[16:26] <cjwatson> I thought Keybuk went through this in detail on #ubuntu-devel a couple of days back?
[16:26] <ogra_cmpc> yes together with pitti and till
[16:27] <ogra_cmpc> yesterday even i think
[16:27] <cjwatson> it's not obvious to me how to fix this
[16:29] <cjwatson> http://irclogs.ubuntu.com/2010/09/14/%23ubuntu-devel.html#t16:28
[16:29] <quadrispro> hi guys
[16:29] <cjwatson> in which Keybuk explains exactly why this is broken
[16:30] <cjwatson> pitti: so remember how the consensus on Tuesday seemed to be "ok, it will break if you start or stop smbd manually, but just don't do that" ...
[16:31] <cjwatson> pitti: bit of an upgrade issue there ;-)
[16:31] <pitti> cjwatson: just got a DSL reconnect, so I guess I missed a bit of the conversation
[16:31] <pitti> cjwatson: oh, right
[16:31] <pitti> you mean if we upgrade the samba package, it'll wait forever on cups
[16:32] <cjwatson> and indeed it's doing so for lots of people
[16:32] <cjwatson> bug 639768
[16:32] <pitti> urgh, so we better revert this for now, I think
[16:33] <pitti> I haven't seen a good solution for "start cups before samba" yet
[16:33] <cjwatson> perhaps we can decouple those two jobs, and instead signal samba somehow when cups is ready for it?
[16:33] <cjwatson> reverting the entire upstartification may be painful
[16:33] <pitti> that's the tricky bit -- you can have a system with samba and without cups
[16:33] <cjwatson> the upgrade rules aren't designed for that
[16:33] <pitti> cjwatson: oh, I'd keep the upstart job
[16:33] <pitti> cjwatson: just drop the "on starting smbd"
[16:34] <cjwatson> right
[16:34] <pitti> the upstart script works fine, I think we can just as well keep it
[16:34] <pitti> (except for that bit, of course)
[16:34] <cjwatson> well, if you're signalling samba in a way which doesn't involve direct arcs in the upstart job graph, that would be easier
[16:34] <cjwatson> you know, if you could send SIGHUP to it or something
[16:34] <cjwatson> if it fails, whatever
[16:35] <pitti> slangasek: ^ is there a way to tell smbd "go redetect the configuration" like this? (SIGHUP etc.)
[16:36] <soren> pitti: As in reread its configuration file?
[16:36] <soren> pitti: Or what exactly changes that samba needs to notice?
[16:36] <slangasek> pitti: to go reread smb.conf?  sure, SIGHUP does it
[16:36] <pitti> soren: I don't think that's in samba's configuration file; I guess it just asks cups?
[16:36] <mathiaz> pitti: http://manpages.ubuntu.com/manpages/maverick/en/man8/smbd.8.html
[16:36] <soren> pitti: My problem is that I don't know what "that" is in your question.
[16:37] <mathiaz> pitti: you can force a reload by sending a SIGHUP to the server.
[16:37] <pitti> soren: if only I knew :)
[16:37] <cjwatson> will SIGHUP be sufficient to get it to notice that cups is now available?
[16:37] <soren> Ok, why does CUPS need to wait for Samba?
[16:37] <pitti> soren: I was told that we should start cups before smbd, so that smbd can pick up cups' printers and export them to the windows network
[16:37] <slangasek> I believe so but would have to test that
[16:37] <soren> Ah, I see.
[16:37] <pitti> soren: but I don't know whether samba is using libcups or reading /etc/cups/printers.conf, etc.
[16:38] <pitti> mathiaz: grabbing the bug, FYI
[16:38] <mathiaz> pitti: ok
[16:41] <ttx> ok, so this happens to be the first samba update since that problematic cups update, IIUC
[16:42] <mathiaz> ttx: yes
[16:42] <cjwatson> perhaps, after cups is fixed, samba ought to be reuploaded with a Breaks: cups (= thatversion)
[16:42] <ttx> mathiaz: unlucky you :)
[16:43] <mathiaz> ttx: well - better now than when the first security update for samba in maverick is published
[16:43] <pitti> so I wonder whether I should only drop the "on starting smbd" for now, or add a killall -HUP smbd as well
[16:43] <ttx> mathiaz: heh, yes
[16:44] <cjwatson> use 'status' to find the pid of smbd according to upstart
[16:44] <cjwatson> (yes, you have to do a little text parsing)
[16:44] <pitti> cjwatson: except that there are two smbd processes
[16:44] <pitti> $ status smbd
[16:44] <pitti> smbd start/running, process 1213
[16:44] <pitti> root      1213  0.0  0.1  93504  4784 ?        Ss   13:35   0:00 smbd -F
[16:44] <pitti> root      1226  0.0  0.0  93504  1988 ?        S    13:35   0:00 smbd -F
[16:44] <cjwatson> but at least the format is documented
[16:44] <cjwatson> oh
[16:44] <pitti> 1226 is a child
[16:44] <cjwatson> which one do you need to SIGHUP?
[16:44] <cjwatson> is it sufficient to SIGHUP the top one?
[16:45] <pitti> also, I'm not sure whther that'd help at all
[16:45] <pitti> The configuration file, and any files that it includes, are
[16:45] <cjwatson> I'd suggest just dropping 'on starting smbd' for now while we research thiss
[16:45] <pitti>        automatically reloaded every minute, if they change. You can force a
[16:45] <cjwatson> *this
[16:45] <pitti>        reload by sending a SIGHUP to the server.
[16:45] <mathiaz> pitti: right - I'm not sure either
[16:45] <cjwatson> but the configuration file is not changed in this case
[16:45] <pitti> i. e. it doesn't seem necessary nor sufficient
[16:45] <mathiaz> pitti: I'm not sure smbd would pick up the new printers
[16:45] <cjwatson> the thing that changes is cups starting, which smbd can't detect
[16:46] <pitti> ok, let's just drop the dependency for now
[16:47] <mathiaz> pitti: if you drop the dependency and *restart* smbd in the post-script section of cups?
[16:47] <mathiaz> pitti: hm - well - that would probably break existing smbd sessions
[16:48] <pitti> mathiaz: that, and would be rather costly, too
[16:49] <pitti> let's figure this out under less pressure; this has been broken for ages, after all
[16:51] <pitti> uploaded for now
[16:55] <pitti> a really cheesy workaound might also be to start smbd later? i. e. "start on runlevel [2345]" instead of "start on local-filesystems"?
[16:56] <cjwatson> don't leave it up to chance like that, please
[16:57] <cjwatson> we'll just get confused later
[16:58] <mathiaz> pitti: ok - so the starting on smbd has been removed
[16:58] <mathiaz> pitti: for now smbd will not pick up new printers from cups?
[16:58] <pitti> mathiaz: right, same situation as since karmic
[16:59] <mathiaz> pitti: ok
[17:00] <pitti> tkamppeter: ^ FYI
[17:00] <mathiaz> pitti: should samba be reuploaded with a breaks as suggested by cjwatson ?
[17:00] <pitti> mathiaz: I'm not sure under which conditions that would help
[17:01] <pitti> but it's certainly not wrong
[17:01] <cjwatson> come to think of it I can't think of a condition where it would help
[17:01] <cjwatson> I was thinking of upgrades from lucid, but those will just upgrade to the fixed cups
[17:01] <cjwatson> perhaps partial upgrades
[17:01] <cjwatson> ah yes
[17:02] <cjwatson> user has already upgraded cups to the version currently in the archive, before pitti's fix today; there's some attractive bug-fix in samba, so they run 'apt-get install samba'
[17:02] <cjwatson> bang
[17:02] <cjwatson> a Breaks would encourage the package manager to upgrade cups as well
[17:07] <mathiaz> cjwatson: well there was only one upload after the upstartification of cups
[17:07] <cjwatson> yes, but there might be more
[17:07] <cjwatson> partial upgrades - we can't necessarily assume that users are up to date on all packages in a level way
[17:08] <cjwatson> particularly during development cycles when one thing or another is often broken, or when people sometimes just change one thing at a time
[17:09] <mathiaz> cjwatson: gotcha
[17:09] <mathiaz> cjwatson: so the following line should be added to the debian/control file of the samba package: Breaks: cups (= 1.4.4-4) ?
[17:10] <jelmer> pitti, mathiaz: our print dev hasn't gotten back to me yet, but I've looked at the code and its intend at least is that the printers are reloaded on SIGHUP.
[17:10] <pitti> jelmer: ah, splendid
[17:10] <pitti> jelmer: thanks a lot for checking
[17:10] <pitti> jelmer: while you are there: I have two smbd processes, one is the child of the other
[17:10] <mathiaz> cjwatson: 1.4.4-4 being the version that added the upstart job, 1.4.4-4ubuntu1 being the one that pitti just uploaded
[17:11] <pitti> jelmer: is it enough to send sighup to the parent, or do I need both?
[17:11] <pitti> mathiaz: right, -4 is the only one that wreaks havoc
[17:12] <mathiaz> pitti: ok - so I'll upload a new version of the samba package wich add a Breaks line
[17:12] <pitti> mathiaz: cheers
[17:13] <tkamppeter> pitti, the Ricoh guys are suggesting to let a straight PS workflow (pstops filter) happen when printing  PS on a PS filter. see e-mail.
[17:13] <jelmer> pitti: not sure, I'll check
[17:14] <cjwatson> pitti: right
[17:14] <cjwatson> er
[17:14] <cjwatson> mathiaz: right, that's what I'm thinking
[17:14] <jelmer> pitti: fwiw it should update the list every "printcap cache time" seconds as well (defaults to 750)
[17:14] <pitti> jelmer: ah, so it'll work after 13 minutes anyway?
[17:14] <jelmer> pitti: I'm betting that's not an ideal time to have to wait for printers to come up on startup though..
[17:14] <tkamppeter> pitti, they do it for two reasons: 1. They observe yellow backgrounds with some files, but this I cannot reproduce. I also have already fixed such kind of bug.
[17:14] <jelmer> pitti: yep
[17:15] <pitti> jelmer: right, so if sending SIGHUP to the parent smbd will cause it to reload immediately, then doing that is easy
[17:15] <pitti> status smbd -> check for "running" -> parse out pid -> send sighup to that
[17:15] <pitti> but that doesn't give me the child pid, just the parent
[17:16] <tkamppeter> pitti, 2. There is a file which makes one of the Ricoh printers hang with the current workflow.
[17:16] <pitti> tkamppeter: can we control the filter priorities (ps vs. pdf) on a per-driver level even?
[17:18] <tkamppeter> pitti, no. The suggestion is to slightly lower the cost factor of pstops, so that only for the "input is PS and printer is PS" case the PS workflow happened. Possible solutions are implementing this or adding a remark in README.Debian.
[17:18] <pitti> tkamppeter: why do we do ps -> pdf -> ps at all? so that we can do transformations like "4-on-1" in between?
[17:18] <tkamppeter> pitti, the suggested change is replacing
[17:19] <tkamppeter> application/pdf                 application/vnd.cups-postscript 66      pdftops
[17:19] <tkamppeter> by
[17:19] <tkamppeter> application/pdf                 application/vnd.cups-postscript 65      pdftops
[17:19] <tkamppeter> in /usr/share/cups/mime/mime.convs
[17:20] <pitti> tkamppeter: what's the potential regression from using pstops again?
[17:20] <pitti> that'd apply to all printer drivers, not just Ricoh, right?
[17:20] <pitti> but indeed I remember similar Debian bug reports which said that using ps works better
[17:20] <tkamppeter> pitti, yes, this way we do the page management stuff, like 4-on-1 on PDF data, which always works. PS can be non-DSC-conforming and so a 4-on-1 on PS is not always performed.
[17:22] <tkamppeter> pitti, yes, it applies to all PostScript printers and also to drivers which take only PostScript input (like foo2zjs).
[17:25] <jelmer> pitti: <idra> jelmer, IIRC the parent should send a "reload config" message to all children when it receive a SIGHUP
[17:25] <pitti> jelmer: ah, perfect
[17:26] <pitti> jelmer: thanks a bunch!
[17:26] <pitti> tkamppeter: so, if you think it's better that way, please commit to bzr
[17:26] <jelmer> pitti: you're welcome, upstart ftw!
[17:27]  * jelmer returns to sync source bugfixing
[17:27] <pitti> cjwatson, tkamppeter, slangasek, mathiaz: so I'll add the SIGHUP to cups' post-start
[17:28] <cjwatson> sounds good to me
[17:28] <mathiaz> pitti: sounds good to me as well
[17:31] <pitti> $ status smbd | awk '/process [[:digit:]]+/ { print $NF}'
[17:31] <pitti> that seems to DWIM
[17:33] <slangasek> pitti: technically no
[17:33] <slangasek> pitti: you need to make sure it's 'start/running' if you're going to HUP it
[17:33] <fta> highvoltage, what does it take to have bug 636894 fixed (in time)??
[17:33] <slangasek> so you aren't killing the pre-start script :)
[17:33] <fta> highvoltage (oops, sorry, not for you)
[17:33] <pitti> slangasek: ah, thanks; does it really need to be "start/running", or could it be anything/running?
[17:34] <pitti> slangasek: i. e. "I intend to stop, but can't yet"?
[17:34] <fta> (was "hi, ...")
[17:34] <slangasek> pitti: if it's anything else, there's no reason for you to signal it :)
[17:34] <slangasek> pitti: and in most cases, sending the signal would go to a process that's *not* smbd - so I think you should only worry about start/running
[17:34] <pitti> status smbd | awk '/start\/running, process [[:digit:]]+/ { print $NF}'
[17:34] <pitti> using that then
[17:36] <pitti> ok, I added some logging to cups.conf, seems to work fine
[17:38] <pitti> ok, committed
[17:38] <pitti> tkamppeter: do you plan to do a commit for the ps stuff?
[17:38] <highvoltage> fta: :)
[17:39] <fta> highvoltage, xchat's fault :P
[17:39] <tkamppeter> pitti, yes, I am preparing it now.
[17:49] <tkamppeter> pitti, done.
[17:49] <pitti> tkamppeter: hm, bzr pull doesn't give anything new
[17:49] <pitti> tkamppeter: 11 minutes to go until freeze starts :)
[17:51] <tkamppeter> pitti, resolved conflict and pushed again.
[17:52] <pitti> hm, that commit looks weird
[17:52] <pitti> tkamppeter: did you push --overwrite?
[17:52] <pitti> on a conflict, you should uncommit, pull, fix, and commit again
[17:53] <micahg> any AA available for a main sync before Final Freeze (6 minutes)?
[17:53] <cjwatson> micahg: yes
[17:53] <tkamppeter> pitti, I did only bzr push. I never used --overwrite.
[17:53] <micahg> cjwatson: bug 636894 please :)
[17:53] <cjwatson> is ubuntu-archive already subscribed to it?
[17:53] <micahg> yes
[17:54] <cjwatson> ok, then I'll just do a sync-helper pass
[17:54] <tkamppeter> pitti, conflict was only in debian/changelog, I have made sure that your newer comment got used.
[17:54] <cjwatson> (of course, archive admin syncs bypass freezes anyway ... *cough*)
[17:54] <cjwatson> at least I think they do, could be wrong
[17:54] <micahg> cjwatson: does that script require a core-dev comment?
[17:55] <cjwatson> not necessarily, it's interactive so we can apply judgement
[17:55] <micahg> cjwatson: ah, ok
[17:55] <cjwatson> though generally a main sync should have a main uploader's approval
[17:55] <micahg> cjwatson: it has one indirectly
[17:55] <cjwatson> however, I can look at it since you asked nicely
[17:56] <micahg> cjwatson: thank you :)
[17:56] <pitti> tkamppeter: please bzr pull  --overwrite; I fixed the branch
[17:56] <pitti> tkamppeter: for some reason the last rev was messed up
[17:57] <tkamppeter> pitti, did my attempt to solve the conflict revert the upstart script?
[17:57] <pitti> tkamppeter: I don't know, I didn't look (want to get this uploaded..)
[17:58] <pitti> the topmost change was a weird merge and shuffled the changelog
[17:58] <tkamppeter> pitti, did you fix it, so that you can upload?
[17:58] <pitti> tkamppeter: yes, doing now
[17:59] <fta> cjwatson, thanks! (for libvpx)
[17:59] <pitti> tkamppeter: 2 mins before freeze, nice timing! /me ^5s you
[18:00] <tkamppeter> pitti, printing stack has boarded on last call, now we have a great Maverick (especially on Ricoh users).
[18:01] <pitti> we lift off in time
[18:02] <tkamppeter> pitti, to land exactly om 10/10/10 at 10:10:10.
[18:02] <cjwatson> micahg: gar, another bug blocked on bug 635591
[18:03] <tkamppeter> pitti, on the advertizing screen of the metro of Berlin they announce release parties. I hope they will this time stop the metro for one minute to announce this great event :-).
[18:03] <pitti> http://people.canonical.com/~pitti/scripts/syncpackage FTW?
[18:03] <cjwatson> micahg: I think we can give this a freeze exception though
[18:03] <cjwatson> pitti: the fix is supposed to land soon, and there is another bug blocked on it
[18:03] <pitti> ah
[18:03]  * cjwatson prefers not to use syncpackage if possible
[18:14] <pitti> (the archive is not quite "open" any more)
[18:22] <micahg> cjwatson: ok, thanks, should I subscribe to the soyuz bug and poke about libvpx when it's cleared
[18:22] <cjwatson> I'm subscribed to the Soyuz bug, and have noted in it all the bugs which it blocks
[18:22] <cjwatson> so I'll go through them myself
[18:23] <micahg> cjwatson: great, thank you
[18:57] <ari-tczew> does anyone from archive-admins is working on syncs?
[18:57] <ari-tczew> (right now)
[19:07] <chrisccoulson> ari-tczew, see the topic
[19:07] <ari-tczew> ok chrisccoulson
[19:41] <cjwatson> ari-tczew: I've been doing them at least daily for the last two weeks, and I processed one of yours immediately before the freeze.
[19:42] <ari-tczew> cjwatson: yes, thanks
[19:42] <cjwatson> ari-tczew: but as of now, as chrisccoulson points out, any change needs a final-freeze exception and needs a very good reason
[19:42] <cjwatson> ari-tczew: although actually, if it's in universe and not on the CDs, it's still OK
[19:43] <ari-tczew> cjwatson: I would upload a new package - clementine. it's a music player. what are the chances to upload?
[19:45] <cjwatson> ari-tczew: you can certainly upload it; whether we accept it would be a judgement call on how complex it looks
[19:45] <cjwatson> I suppose chances would be moderate
[19:46] <cjwatson> it's a question of whether it's likely to need significant fixes to be of release quality
[19:46] <ari-tczew> cjwatson: it's not related to main packages, so ubuntu's API won't be broken. :)
[19:46] <cjwatson> I know, but the quality of universe does matter too
[19:46] <cjwatson> as a MOTU you should be keen on that ;-)
[19:48] <ari-tczew> cjwatson: ubuntu-release will decide about upload. :)
[19:53] <ScottK> ari-tczew: You shouldn't propose it unless you are convinced it is appropriate.  We've got pleanty of things to do already.
[19:54] <ari-tczew> ScottK: I'm convinced about this upload. It's a great music player and we should ship it with Maverick release.
[19:54] <ScottK> ari-tczew: Why not just wait a month, put it in Natty, and then backport it?
[19:55] <ari-tczew> ScottK: why not now?
[19:55] <ScottK> Because the people that would have to review it are all busy with other things.
[19:55] <ScottK> If we do it now, some other thing doesn't get done.
[19:59] <ari-tczew> ScottK: I'm sad to hear this.
[19:59] <ScottK> ari-tczew: This is why we have a new package deadline in the release schedule.
[20:00] <ari-tczew> ScottK: when is the deadline for new packages?
[20:01] <ScottK> ari-tczew: Same as feature freeze, August 12.
[20:01] <highvoltage> ari-tczew: I don't think it's completely rational being disappointed, the deadline for new packages was more than a month ago already: https://wiki.ubuntu.com/MaverickReleaseSchedule
[20:02] <highvoltage> ari-tczew: usually, after that, a FFU (or Feature Freeze Exception) has to be filed to get a new package in: https://wiki.ubuntu.com/FreezeExceptionProcess
[20:03] <ari-tczew> ScottK: what do you need review in package?
[20:03] <highvoltage> ari-tczew: after Final Freeze (today), upi
[20:03] <highvoltage> oops, well, after final freeze you'll need an exception for that too
[20:06] <ari-tczew> highvoltage: I know. 2 years ago also I provided FFe for kadu upgrade.
[20:06] <ari-tczew> but it wasn't a new package like clementine right now.
[20:07] <ScottK> ari-tczew: It's somewhat described in https://wiki.ubuntu.com/ArchiveAdministration
[20:10] <ari-tczew> ScottK: when we will backport package from natty, new package will be published in -release pocket or -backport?
[20:10] <ScottK> ari-tczew: Backport
[20:11] <ari-tczew> ScottK: quite so I'm afraid. I'd give users this music player at start.
[20:12] <ScottK> ari-tczew: I can understand being disappointed, but it's highly unlikely you'll get an FFe for it approved now.
[20:12]  * ScottK has other this to get busy with.
[20:13] <highvoltage> ari-tczew: moral of the story: if you want your packages in the archive, try to follow the schedule :)
[20:14] <ari-tczew> ScottK: what about other admins?
[20:15] <ScottK> I think it's unlikely.
[20:21] <ari-tczew> ScottK: ok, but I can request FFe, right?
[20:21] <ScottK> ari-tczew: You can.  I'd prefer you spend your time fixing FTBFS or NBS instead, but you can.
[20:23] <cjwatson> ari-tczew: I thought you were focusing on security until release, btw? ;)
[21:06] <ari-tczew> cjwatson: that's right. however, I loved use amarok 1.4 and clementine can give me similiar enjoy. I'd give people this great program. It can be a small argument for choice Ubuntu. ;)
[21:09] <kees> ari-tczew: added you to ubuntu-sponsors
[21:11] <ari-tczew> kees: thanks. :)
[21:12] <kees> ari-tczew: np :)
[22:03] <doko> Riddell: kdoctools : Depends: kdelibs5-data (= 4:4.5.1-0ubuntu4) but 4:4.5.1-0ubuntu5 is to be installed
[22:04] <doko> please stop this insanity!  makes the packages uninstallable until built on armel too ...
[22:14] <lex79> doko: kdoctools needs kdelibs5-data for dtd/kdex.dtd needed to build docs
[22:15] <ogra_cmpc> lex79, i think doko refers to the =
[22:15] <doko> exactly ...
[22:15] <doko> that should be a >= 4.5.1
[22:16] <lex79> ah, now it is kdelibs5-data (= ${source:Version})
[22:16] <lex79> I can change to >=  ${source:Version}
[22:16] <doko> lex79: doesn't help, think about it
[22:16] <lex79> uhm right ;)
[22:17] <lex79> I can drop that (= ${source:Version})
[22:17] <ogra_cmpc> you actually want the upstream version
[22:17] <ogra_cmpc> (and the epoch)