| matttbe | but it's not a problem to have (>= 2.1.3-9) :) | 00:00 |
|---|---|---|
| Laney | anyway I won't insist on that change | 00:00 |
| Laney | but I think you might want cairo-dock-dev (<< 2.1.3-10-lucid.1~) too | 00:00 |
| matttbe | mmh, yes maybe you're right | 00:01 |
| * persia gets a little disturbed by the packaging message "warning: using ubuntu without xulrunner-dev. we reccomend installing it" : that at least deserves some attribution definining "we". | 00:03 | |
| micahg | persia: which package? | 00:06 |
| persia | micahg: I got the message building mongodb source. I'm unsure which package generates it. | 00:06 |
| micahg | persia: k, seems weird | 00:06 |
| persia | At least surprising. | 00:07 |
| * jdong scratches head at http://i.imgur.com/fWsQv.png | 00:18 | |
| persia | jdong: Why is this confusing? | 00:19 |
| jdong | persia: trying to figure out what usecase this is for. | 00:20 |
| persia | People giving presentations. | 00:20 |
| jdong | I've always moaned about the usefulness of OOo Impress vs Powerpoint | 00:20 |
| jdong | but this seems like a step in the opposite direction | 00:20 |
| jdong | maybe I'm being too critical on version 0.1 | 00:20 |
| persia | jdong: 1) you're being critical on version 0.1 2) lots of folks don't need fancy stuff (like me), and prefer to just have a few lines of text with a fairly standard background. | 00:21 |
| persia | That said, consider abiword, gnumeric, etc. | 00:21 |
| Laney | S5 is pretty good for simple presentations | 00:21 |
| jdong | I totally support (2), but I don't think (2) involves removing features from a more powerful presentation tool | 00:21 |
| persia | (and hey, if people want to do stuff, and they enjoy it, let'm do it: maybe something wonderful will happen) | 00:21 |
| jdong | I agree with the latter | 00:22 |
| persia | jdong: Based on racarr's blog entries, I think it's a matter of only having completed the framework and now adding features, rather than stripping an existing tool. | 00:22 |
| jdong | persia: *nods* I'm just a bit bitter from my experiences using Powerpoint vs OOo impress to put together simple presentations.... | 00:23 |
| jdong | counterintuitively, I found PowerPoint much easier to use in that I spent less time wrestling with the tool | 00:23 |
| jdong | nice touches like automatically transforming bulleted lists (outlines) into flowchart graphics | 00:24 |
| persia | jdong: You could always use tex | 00:24 |
| jdong | persia: yup, that's typically been what I've done -- except the TeX slide-making software suffers from the general problem with TeX in my experience -- god forbid you actually want to tweak an existing style/template | 00:25 |
| persia | Of course you don't. Clearly, you want to write your own :) | 00:25 |
| jdong | hehehe that actually does sound like fun | 00:26 |
| * persia used to love TeX and is now somewhat happier to admire it's glory from afar | 00:26 | |
| jdong | *nods* :) | 00:26 |
| persia | But *no* other tool I've ever seen lets you do what TeX lets you do. | 00:26 |
| Laney | TeX is bigger and more muscly than you: fight it at your considerable peril | 00:27 |
| persia | Indeed, but if you can make freinds... | 00:27 |
| jdong | I still love TeX a lot | 00:27 |
| persia | May you continue to do so for many years | 00:27 |
| jdong | I sure hope so :) | 00:28 |
| Laney | erm | 00:28 |
| * Laney spies a lot of dpkg-shlibdeps warnings | 00:28 | |
| persia | The key to continuing to get along is to never end up not using it for a protracted period. Relearning TeX is harder than learning it the first time. | 00:28 |
| Laney | matttbe: cairo-dock doesn't seem very multi monitor aware :( | 00:41 |
| Laney | (uploading the plugins) | 00:41 |
| matttbe | matttbe: of course yes :) it depends of what you have set in Position | 00:42 |
| matttbe | with xinerama (Advanced mode) | 00:42 |
| Laney | I'm just talking about the first launch | 00:42 |
| matttbe | mmh yes, it's maybe better to enable xinerama and set the monitor 0 by default? | 00:43 |
| Laney | I wouldn't know what the potential implications of that are ;) | 00:43 |
| matttbe | :) in fact, no developer has a dual monitor :) | 00:44 |
| matttbe | so when there is a bug, it's hard to fix it :) | 00:44 |
| Laney | is there any reason why ${shlibs:Depends} isn't on the integration package? | 00:44 |
| matttbe | no problem for me except with libGL.so because I've installed nvidia drivers from nvidia website | 00:45 |
| Laney | shouldn't be a problem | 00:45 |
| Laney | I'm going to add it and upload | 00:45 |
| matttbe | no ! | 00:45 |
| matttbe | sorry, I'm tired :) | 00:45 |
| fabounet | integration package doesn't require the dependencies | 00:46 |
| matttbe | thanks fabounet :) | 00:46 |
| fabounet | they are not loaded if the librarires is not present on the user's system | 00:46 |
| fabounet | this is because | 00:46 |
| fabounet | they are plug-ins to bind the dock with the Desktop Environment | 00:47 |
| fabounet | like GVFS, KIO, Thunar-VFS | 00:47 |
| matttbe | Laney: so do not add it :) | 00:47 |
| persia | I thought we recommended against xinerama setups these days. | 00:47 |
| matttbe | Laney: this is the reason that I've split integration plug-ins | 00:47 |
| matttbe | fabounet: what do you think of (01:43:15) matttbe: mmh yes, it's maybe better to enable xinerama and set the monitor 0 by default? | 00:47 |
| matttbe | ok | 00:47 |
| fabounet | the correct plug-in is loaded according to your system, the others are ignored | 00:47 |
| Laney | ok | 00:48 |
| Laney | I'm not sure this is a clean solution, but it's what we already have | 00:48 |
| fabounet | well for now it's just a matter of enabling the option in the config panel, it's 1 click | 00:49 |
| fabounet | it could be done by default if we think it's definitey better to have the dock on one screen than on the middle of two screens | 00:49 |
| fabounet | I can't say since I don't have dual screen ^^ | 00:49 |
| matttbe | but it's not useful on the middle of two screens :) | 00:50 |
| Laney | are we going to start using the debian packages? | 00:53 |
| === RoAkSoAx_ is now known as andreserl | ||
| matttbe | thank you for the upload Laney ! | 00:54 |
| Laney | no worries | 00:54 |
| Laney | I hope that in the future we can sync the packages from Debian | 00:54 |
| Laney | so please try to work with the packaging team there | 00:55 |
| matttbe | Laney: mmh, I don't know because we had many problem with the debian packagers :) . Deb packages are already done but he want to rebuild it | 00:55 |
| matttbe | but yes, I will try to do that | 00:55 |
| fabounet | they have quite a particular view of the packaging, like splitting the plug-is package into 30 packages (1 for each plug-in) | 00:56 |
| Laney | that's not so unusual really | 00:56 |
| Laney | it makes sense in the context of a package manager too | 00:57 |
| matttbe | but he has split all plug-ins into different packages, I don't know if it was for the fun or not but it's harder to manage | 00:57 |
| matttbe | it can be good but he only split the binaries and not the data... | 00:57 |
| matttbe | yes, of course | 00:57 |
| Laney | that's the approach I'd favour to be honest | 00:57 |
| Laney | but alas, it's time for bed | 00:58 |
| Laney | goodnight | 00:58 |
| fabounet | I don't like this way for many reasons, but the packager has accepted to make a meta-package that group all the packages in 1, so this is a good solution I think | 00:58 |
| matttbe | thank you Laney and good night | 00:58 |
| Laney | (yes, having a metapackage is also common and a good idea) | 00:59 |
| Laney | (breadth + depth) | 00:59 |
| Laney | byeee | 00:59 |
| fabounet | thanks, good night | 00:59 |
| === RoAkSoAx_ is now known as andreserl | ||
| carstenh | matttbe: he needs to build every package he uploads himself for (i hope) obvious reasons. | 01:22 |
| matttbe | carstenh: yes I understand, it's obviously! | 01:24 |
| matttbe | carstenh: do you know what we have to do now? Just waiting? | 01:25 |
| carstenh | matttbe: I don't know what you want to achieve | 01:26 |
| carstenh | and I didn't read the whole backlog | 01:26 |
| matttbe | :) we want to update two packages in Lucid | 01:27 |
| matttbe | to fixed a annoying crash | 01:27 |
| carstenh | sorry, no idea. someone with upload permissions needs to upload it but I don't know what the recommended way to find a sponsor/uploader is. | 01:28 |
| matttbe | ok, I'll be back tomorrow! | 01:29 |
| carstenh | oh, and I hope you talked about he wanted running dpkg-buildpackage himself, recreating the packaging is useless | 01:29 |
| persia | matttbe: Didn't Laney just sponsor your stuff? | 01:29 |
| matttbe | persia: he has merged my branch into lp:ubuntu/cairo-dock (and plug-ins) | 01:30 |
| matttbe | so I suppose he did the job | 01:30 |
| persia | I beleive he merged and uploaded. | 01:31 |
| matttbe | persia: so what we have to do now? just waiting? | 01:32 |
| persia | matttbe: Yep. You can see the uploads at https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= | 01:32 |
| persia | Now you're waiting for an archive admin to approve them. | 01:33 |
| persia | This isn't likely to happen prior to the RC release. | 01:33 |
| persia | (which is on the 22nd: today for some, tomorrow for others) | 01:33 |
| matttbe | oh great ! Thank you for your help persia | 01:34 |
| persia | matttbe: No problem. Just remember the procedure we went through at the beginning. That ought get you sponsored when you need it in the future. | 01:34 |
| matttbe | yes, ok! | 01:35 |
| matttbe | just another question: when do you go to sleep persia :) ? If I remember well, you lives in Japan | 01:35 |
| persia | It's 9:30 am here, so it's a normal time to be awake. | 01:35 |
| matttbe | ah ok :) | 01:35 |
| persia | That said, I'm not particularly diurnal, so there's no good answer to the question. | 01:35 |
| matttbe | :P | 01:36 |
| ScottK | YokoZar: It's part of the ubuntustudio packageset. I didn't go so far as to check the seeds. Let me look into it. | 01:38 |
| YokoZar | ScottK: persia clarified | 01:38 |
| * ajmitch didn't think that persia actually slept | 01:38 | |
| ScottK | What was rhe result of the clarification? | 01:38 |
| YokoZar | ScottK: it's a build-depend of the package that was FTBFS earlier | 01:38 |
| * ScottK only skimmed 20 hours of backscroll | 01:38 | |
| ScottK | So is it urgent to get in and does ubuntustudio care? | 01:39 |
| persia | No and yes. | 01:39 |
| persia | It would be lovely to get it in just *after* RC release. | 01:39 |
| persia | As most commercial plugins use VST, which is the bit that FTBFS. | 01:40 |
| YokoZar | ScottK: dssi-vst is part of ubuntustudio-audio and is FTBFS because of the wine stuff | 01:40 |
| persia | But images wouldn't be tested if there was a respin now. | 01:40 |
| YokoZar | Well we could update Wine1.2 and Wine but not dssi-vst and that woulnd't cause a respin would it? | 01:40 |
| YokoZar | Either way I suppose it's best to just wait after RC | 01:40 |
| persia | library dependencies ... | 01:40 |
| ScottK | Thank you. | 01:41 |
| ScottK | Is wine-1.2 a run time depends or just build-time? | 01:41 |
| persia | That's my thought. | 01:41 |
| * persia checks | 01:41 | |
| YokoZar | ScottK: wine1.2 or wine can satisfy runtime depends, but wine 1.0 is needed as build dependency, and wine1.0 currently has no binary packages because the dummy packages in wine1.2 (which my upload removes) were overriding them | 01:41 |
| persia | Depends: libwine | 01:42 |
| persia | so runtime | 01:42 |
| YokoZar | persia: I'll also need to do an update of dssi-vst as well | 01:42 |
| YokoZar | persia: that's basically a rename in the control file and rebuild | 01:42 |
| ScottK | Then I either need the appropriate Ubuntu Studio person to say they want to respin for this (and get slangasek to agree to do it) or it needs to wait | 01:43 |
| YokoZar | yeah have it wait | 01:43 |
| persia | waiting sounds easier to me | 01:43 |
| persia | I'm confident that Ubuntu Studio testers won't be able to run through the tests again if there is a respin. | 01:44 |
| persia | (although I'm not the appropriate person) | 01:44 |
| slangasek | slangasek would strongly counsel the Ubuntu Studio people not to do a respin at this stage | 01:45 |
| ScottK | That's what I figured it added up to. | 01:46 |
| === rgreening_ is now known as rgreening | ||
| ScottK | But I was also 10 hours in meetings today with 2 1/2 hours of driving on each end, so my level of focus is not ideal. | 01:47 |
| ScottL | I agree with persia, we struggle to get Ubuntu Studio images tested once, twice probably would not happen | 01:51 |
| * persia suspects ScottL might qualify as the appropriate person | 01:52 | |
| * TheMuso doesn't think we should respin. | 02:02 | |
| micahg | ScottK: ping | 04:45 |
| ScottK | micahg: Pong | 04:45 |
| micahg | ScottK: hi, I just realized I forgot about a package in universe that might need to be upgraded, but I wanted your opinion | 04:45 |
| ScottK | OK | 04:45 |
| micahg | ScottK: mantis is currently at 1.1.8 and 1.2 was released about a month ago | 04:46 |
| micahg | ScottK: 1.2 has a lot of new stuff and no more releases are planned for 1.1.x | 04:46 |
| ScottK | Unless the release is known to fix important bugs/the current one is badly broken, it's probably better to wait and backport from maverick. | 04:47 |
| micahg | ScottK: but there are DB changes between the releases so it's not a simple upgrade | 04:47 |
| ScottK | Even better reason to wait. | 04:47 |
| micahg | ScottK: ah, ok, didn't know that was a good option, ok, I'd prefer to do that actually | 04:47 |
| ScottK | micahg: I'm glad you pinged. I wanted to discuss your libjdic-java upload with you. | 04:47 |
| micahg | ScottK: yes | 04:48 |
| ScottK | Due to the xulrunner specific bit in debian/rules, the package needs updating each time the xulrunner version changes, right? | 04:48 |
| micahg | ScottK: each major version change, not minor I hope | 04:49 |
| ScottK | Wouldn't in make more sense to build-depend on the versioned xulrunner directly? Then all the archive management tools we have would catch this as a package that needed attention. | 04:49 |
| ScottK | As you have it now, it can sliently become unbuildable if xulrunner-dev starts pointing at a new version. | 04:50 |
| micahg | ah, you're saying build on xul-192-dev instead of xulrunner-dev | 04:50 |
| ScottK | Yes | 04:50 |
| micahg | ScottK: makes sense | 04:50 |
| micahg | ScottK: do you want to reject the upload and I'll make that change | 04:50 |
| ScottK | micahg: I'll reject the current upload and you can reuse the same version number. | 04:50 |
| micahg | ScottK: great, I'll have chrisccoulson upload the new version tomrorow | 04:50 |
| ScottK | OK | 04:51 |
| ScottK | Done | 04:51 |
| micahg | the new version from Debian actually FTBFSs, so that's why we kept this version | 04:52 |
| * ajmitch obviously needs to do more to keep the queue busy | 04:52 | |
| ScottK | ajmitch: Yes. Please. | 04:52 |
| ScottK | micahg: Keeping the version that builds is great. | 04:52 |
| micahg | ScottK: I promised to fix it for the next release :) | 04:52 |
| ajmitch | it's the same upstream version though? | 04:53 |
| micahg | ajmitch: yes | 04:53 |
| * ajmitch was wondering why you hadn't merged in the other 3 debian revisions there | 04:53 | |
| micahg | ajmitch: I just started handling the xul rdepends :) | 04:53 |
| ajmitch | brave | 04:53 |
| micahg | ajmitch: hopefully the bravery will be enough to let me be a MOTU :) | 04:57 |
| ScottK | You've got to survive the bravery first. | 04:58 |
| * micahg wonders if he should start fishing for testimonials... | 04:58 | |
| ScottK | That's always the tricky bit with being brave. | 04:58 |
| ScottK | micahg: IME sponsors will start to tell you when they think you're ready. | 04:58 |
| micahg | ScottK: ah, yes, I've heard that | 04:59 |
| ScottK | When you're really ready they make the application for you, but AFAIK that's only happened once and it was for core-dev. | 04:59 |
| micahg | I've gotten better, the first several uploads, it took me 4 or 5 debdiffs before I had it right, now it's usually one or 2 | 05:00 |
| ScottK | That's good. | 05:00 |
| ScottK | Another good sign is when people start being suprised you aren't a MOTU already. | 05:00 |
| * micahg should be patient | 05:00 | |
| micahg | ajmitch: libjdic patch is attached to the bug if you want to sponsor :) | 05:08 |
| micahg | wgrant: ping | 06:41 |
| imbrandon | evening peeps | 06:42 |
| DktrKranz | persia: original branch is lp:~ubuntu-dev/ubuntu-dev-tools/syncpackage | 07:35 |
| === hannesw_ is now known as hannesw | ||
| wgrant | micahg: Hi. | 08:50 |
| micahg | wgrant: hi | 08:51 |
| micahg | wgrant: I was wondering if I can request a xulrunner rdepends category for the multidistrotools | 08:52 |
| micahg | wgrant: for next cycle | 08:52 |
| wgrant | micahg: Not much seems to depend on xulrunner itself -- do you want xulrunner-1.9.2? | 08:54 |
| micahg | wgrant: yes, the binary and build rdepends on xulrunner-1.9.2, xulrunner-dev, or xulrunner-1.9.2-dev would be great | 08:54 |
| micahg | wgrant: also any xul-ext* binaries would be great too | 08:57 |
| micahg | wgrant: or rather their sources | 08:57 |
| micahg | wgrant: would it help if I give you wiki pages with the source pkg names? | 09:01 |
| wgrant | micahg: If there's a list that's kept up to date, I can scrape that. | 09:04 |
| wgrant | Otherwise I'll work out the rbuilddepends stuff. | 09:04 |
| micahg | wgrant: I don't know if it'll be kept up to date | 09:04 |
| dholbach | good morning | 09:21 |
| matttbe | Hey guys! | 09:59 |
| matttbe | there was a problem with the compilation of the new version of Cairo-Dock https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/568083 | 10:00 |
| ubottu | Launchpad bug 568083 in cairo-dock-plug-ins "Please update Cairo-Dock to v2.1.3-10" [Undecided,Fix released] | 10:00 |
| matttbe | I see in the buildlog that plug-ins have been compiled with the 'old' version of cairo-dock-core and cairo-dock-dev (the API) (2.1.3-6) and not with the new version as core (2.1.3-10-lucid). | 10:01 |
| matttbe | I've added a restriction (cairo-dock-dev (>= 2.1.3-9)) but it has downloaded the old version (Get:160 http://ftpmaster.internal/ubuntu/ lucid/universe cairo-dock-dev 2.1.3-6-0ubuntu1 [106kB]) | 10:01 |
| matttbe | So the package needs to be re-compiled | 10:02 |
| matttbe | without any changes | 10:02 |
| matttbe | what can I do? | 10:02 |
| === james_w`` is now known as james_w | ||
| c_korn | is this warning also true for upstart jobs ? http://pastebin.com/DjeLRJEf | 11:14 |
| hyperair | upstart jobs are in /etc/init/blah.conf | 11:19 |
| hyperair | not in /etc/init.d/blah | 11:19 |
| slangasek | c_korn: it's a bug in lintian to show that warning for upstart jobs; the current lintian in lucid isn't supposed to show that warning for upstart jobs | 11:20 |
| * hyperair wonders why debian doesn't switch to upstart. it seems to be really awesome. | 11:20 | |
| c_korn | hm, there is just a file "upstart" in the debian directory. so it gets installed to the wrong directory ? | 11:21 |
| c_korn | (the debian/rules uses cdbs) | 11:22 |
| hyperair | man dh_installinit | 11:22 |
| hyperair | cdbs should also call it | 11:22 |
| slangasek | hyperair: because upstart doesn't support non-Linux kernels | 11:23 |
| slangasek | c_korn: what version of lintian are you using? | 11:23 |
| hyperair | slangasek: oh =( | 11:23 |
| hyperair | slangasek: why not? | 11:23 |
| slangasek | hyperair: because it relies on lots of cutting-edge (non-standard) Linux kernel features to do its job | 11:24 |
| hyperair | slangasek: ah i see. | 11:24 |
| c_korn | slangasek: 2.3.4ubuntu2 | 11:26 |
| slangasek | c_korn: link to the package? | 11:26 |
| slangasek | (the wiican package) | 11:27 |
| c_korn | http://revu.ubuntuwire.com/revu1-incoming/wiican-1001021618/wiican-0.2.1/debian/ | 11:27 |
| c_korn | http://revu.ubuntuwire.com/p/wiican | 11:27 |
| Anasule | Hello, anyone here who works on the evtouch package? | 11:27 |
| slangasek | c_korn: aaah, why in the world is that device mode 0666? | 11:30 |
| slangasek | c_korn: ok, double-checking here, it seems that the lintian check is still buggy | 11:30 |
| slangasek | c_korn: lintian should not warn about missing rc?.d symlinks for upstart jobs, because the /etc/init.d/ script is just a compatibility wrapper | 11:31 |
| slangasek | c_korn: btw, 'invoke-rc.d udev restart' in the postinst is wrong; you should be calling udevadm trigger --subsystem-match=<foo> --action=change | 11:34 |
| c_korn | lrwxrwxrwx root/root 0 2010-04-22 11:32 ./etc/init.d/wiican -> /lib/init/upstart-job | 11:35 |
| slangasek | yes | 11:36 |
| Anasule | If i want to get a touch screen added to the evtouch package whats the best way of doing it please? | 11:40 |
| === nobawk is now known as zz_nobawk | ||
| === zz_nobawk is now known as nobawk | ||
| === nobawk is now known as zz_nobawk | ||
| juli_ | Hi everybody! There is a high importance bug in netbeans package. Should I follow a SRU to fix it or there is a chance to get an approval from motu-release and upload as an exception? | 12:49 |
| ScottK | juli_: We are still accepting bug fixes. | 12:50 |
| ScottK | So I'd suggest try to get it in for release. It will be easy enough to retarget to an SRU if it doesn't make it. | 12:50 |
| juli_ | ScottK, thanks! so I should create a debdiff for a fix and ask an exception ... where? | 12:51 |
| ScottK | juli_: If it's just a bugfix you don't need to ask the release team, just subscribe ubuntu-sponsors. | 12:51 |
| juli_ | actually I have rights for upload of netbeans package.. but I thought it is a freeze | 12:52 |
| ScottK | juli_: There is, but the releae team will review it in the queue after upload. | 12:53 |
| ScottK | Formal FFe is only needed for new features. | 12:54 |
| ScottK | At this point we just review everything. | 12:54 |
| juli_ | ScottK, so for me it is the same upload as usually, right? | 12:54 |
| Laney | matttbe: You should find out why the versioned BD didn't work and then ask for it to be uploaded again | 12:55 |
| matttbe | Hello, the latest version of Cairo-Dock-Plug-Ins has not been compiled with the right version of Cairo-Dock. I've reported the bug, the branch and the patch there : https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/568083 | 12:55 |
| ubottu | Ubuntu bug 568083 in cairo-dock-plug-ins "Please update Cairo-Dock to v2.1.3-10" [High,Confirmed] | 12:55 |
| ScottK | juli_: Yes. Please just be sure to explain yourself well in debian/changelog | 12:55 |
| juli_ | ScottK, ok, thank you a lot! | 12:55 |
| ScottK | juli_: ping me after you upload and I'll look right away. | 12:55 |
| matttbe | Laney: I see in the buildlog that plug-ins have been compiled with the 'old' version (2.1.3-6) and not with the new version as core (2.1.3-10-lucid). I've added a restriction (cairo-dock-dev (>= 2.1.3-9)) but it has downloaded the old version (Get:160 http://ftpmaster.internal/ubuntu/ lucid/universe cairo-dock-dev 2.1.3-6-0ubuntu1 [106kB]) So the package needs to be re-compiled | 12:55 |
| juli_ | ScottK, ok | 12:56 |
| Laney | matttbe: yes, but *why* didn't the version constraint work? | 12:56 |
| Laney | shouldn't this be enforced in the upstream configure script as well? | 12:57 |
| matttbe | I don't know... maybe a bug with the builder | 12:57 |
| Laney | no, I doubt that | 12:57 |
| matttbe | :) | 12:57 |
| Laney | laney@pheasant> dpkg --compare-versions 2.1.3-6-0ubuntu1 ge 2.1.3-9 && echo yes ~ | 12:58 |
| Laney | yes | 12:58 |
| Laney | see | 12:58 |
| Laney | it's the version constraing that is broken | 12:58 |
| ScottK | In any case a new upload will solve it and please do so soon, I'd like to get as much Universe stuff in now before the Main post-RC changes take the builders | 12:58 |
| didrocks | ScottK: hey, should we still ping an archive admin for sync req or use pitti's script? | 12:58 |
| matttbe | Laney: yes but there is an restriction... | 12:58 |
| Laney | I know, but I'm saying that is is *not working* | 12:58 |
| matttbe | yes I see | 12:58 |
| Laney | probably because of the - in the upstream version, but I'm not sure | 12:58 |
| Laney | anyway I'll upload the rebuild | 12:58 |
| matttbe | Laney: I've post a tiny patch | 12:59 |
| Laney | that doesn't fix the issue, but it should be alright anyway as the new cairo-dock has been published now | 12:59 |
| matttbe | Laney: with the previous version (2.1.3-6) this restriction worked: it failed for some arch because the version of cairo-dock-dev wasn't >= 2.1.3-6 | 13:01 |
| Laney | it works if you put a - at the end | 13:02 |
| Laney | I'll do that | 13:02 |
| Laney | (but it would be easiest if you just used . in your versions) | 13:02 |
| matttbe | Laney: ok I see | 13:03 |
| matttbe | Laney: BTW thank you for you help and sorry for the problem :) | 13:05 |
| Laney | these things happen ;) | 13:06 |
| === vish is now known as mac_v | ||
| === mac_v is now known as vish | ||
| Laney | Is it safe to push a packaging branch which I merged using import-dsc? | 13:22 |
| Laney | as in, the importer hadn't caught up with Debian | 13:22 |
| ScottK | Laney: If you don't upload now, you may miss the pre-RC window. | 13:27 |
| ScottK | juli_: ^^^ | 13:27 |
| ScottK | I'm about to be away for a while and I don't know exactly when it will come out. | 13:27 |
| Laney | ScottK: test building | 13:28 |
| ScottK | OK. | 13:28 |
| Laney | I can upload without doing that if you want | 13:28 |
| ScottK | Go ahead and upload and then once you're done ping me it's OK to accept. | 13:28 |
| ScottK | If it doesn't go well it's easy enough to reject. | 13:29 |
| Laney | ok | 13:29 |
| juli_ | ScottK, I've just uploaded... hope it is not too late | 13:29 |
| ScottK | Shouldn't be. | 13:34 |
| Zombie | Greetings. | 13:35 |
| Laney | ScottK: seems good, please accept | 13:36 |
| juli_ | ScottK, I also attached debdiff to a bug in case if you want to see the changes | 13:36 |
| Laney | ScottK: I'm also uploading a merge of pandoc | 13:37 |
| Laney | to fix FTBFS on sparc and armel | 13:38 |
| ScottK | OK. | 13:39 |
| juli_ | ScottK, thank you! | 13:48 |
| === ogra_ is now known as ogra | ||
| Laney | I'm not getting any mail from soyuz about the pandoc upload | 14:20 |
| Laney | oh, but it is in the queue | 14:24 |
| Zombie | ScottK: Can we discuss hardware issues? | 14:25 |
| didrocks | ScottK: can you accept glabels please? I've updated to the new version in Debian and synced in Ubuntu. It fixes an issue with new glib: you can now add items to your label instead of having a segfault :) | 14:33 |
| sebner | huhu RainCT | 14:43 |
| RainCT | Hey sebner | 14:43 |
| kreuter | persia: are you around? | 14:46 |
| ScottK | directhex: I adid accept it. | 15:17 |
| ScottK | Zombie: I'm reasonably certain I'm not the right person to talk to. | 15:18 |
| ScottK | directhex: Sorry, that wasn't meant for you. | 15:18 |
| directhex | moo? | 15:18 |
| ScottK | It was meant for didrocks and since he's not here, you got the tab complete. | 15:19 |
| didrocks | ScottK: I'm there :) | 15:20 |
| didrocks | ScottK: but if you are using weechat, there is some weird tab complete with it at least | 15:20 |
| ScottK | didrocks. Odd, my client doesn't show you. | 15:20 |
| didrocks | ScottK: oh? | 15:20 |
| didrocks | ScottK: well, in any case, thanks for accepting it :) | 15:21 |
| ScottK | You neither show up in the user list nor are available for tab complete. | 15:21 |
| didrocks | ScottK: which client are you using? | 15:21 |
| ScottK | didrocks: We are still processing sync requests, so you could have filed it as a normal one, FYI. | 15:21 |
| ScottK | didrocks Quassl | 15:21 |
| ScottK | ...sl/sel | 15:21 |
| didrocks | ScottK: ok, I wasn't sure about using pitti's script or not. I'll file new one if needed as normal | 15:22 |
| didrocks | well, I'll ask to nijaba, he is using the same client | 15:22 |
| didrocks | others seems to see me | 15:22 |
| didrocks | don't know if bip proxy is putting a weird property on the server side :/ | 15:23 |
| ScottK | YokoZar: wine1.2 is accepted once it's built/published on the archs it build on, feel free to upload whatever it was that need to come after it. | 15:42 |
| persia | kreuter: Am now. Fiddling with diffs. | 15:59 |
| kreuter | persia: great. let me know if anything doesn't make sense. | 15:59 |
| micahg | ScottK: there is a bug-fix/security update for vlc today, can we still take that, or do we need to wait for SRU, only non-bug fixes are translation updates | 16:00 |
| persia | kreuter: Not so far, although some of the diffs didn't apply cleanly to the package: it's more a matter of getting distracted in the middle. | 16:00 |
| ScottK | micahg: If it can be built/tested by ~Sunday we can probably take it. | 16:00 |
| ScottK | It shuld have testing beyond "it builds" | 16:01 |
| ScottK | u/ou | 16:01 |
| micahg | ScottK: I'll see what I can do, thanks | 16:01 |
| micahg | if I get lucky, it'll get into Debian before then :) | 16:01 |
| persia | micahg: Is there any reason that Build-Depends: and Depends: xulunner-dev should cause issues? Some other patches are required for xulrunner-1.9.2-dev, but I'm wondering how tight to set build-deps/deps | 16:21 |
| micahg | persia: for which package? | 16:21 |
| persia | micahg: bug #557024 | 16:21 |
| ubottu | Launchpad bug 557024 in mongodb "mongo / mongod as packaged can't load libmozjs.so" [Undecided,New] https://launchpad.net/bugs/557024 | 16:21 |
| persia | The patch doesn't apply, so I'm pulling out bits. | 16:21 |
| kreuter | persia: I'm sorry, should I generate another patch? | 16:22 |
| micahg | persia: how are you doing mozjs? I made a wrapper for another app | 16:22 |
| kreuter | I might have taken that diff against our upstream master, not 1.2.x. | 16:23 |
| micahg | persia: it seems that if you're using xulrunner-1.9.2 script to get the GRE/dir then you should directly depend on the appropriate dev package | 16:23 |
| persia | micahg: Is that best practice, or is there another way kreuter should do it? | 16:23 |
| micahg | persia: it's best practice for now AFAIK ( I assume you're talking about mozjs) | 16:24 |
| persia | micahg: Yep. OK. Thanks. | 16:24 |
| micahg | persia: here's what I did for edbrowse: http://launchpadlibrarian.net/43565621/edbrowse_3.4.1-1_3.4.1-1ubuntu1.diff.gz | 16:25 |
| persia | kreuter: No worries: it's close enough: I just wanted to also check that it's right. | 16:25 |
| * micahg wonders how we missed that | 16:25 | |
| persia | micahg: Right. Thanks. | 16:25 |
| persia | micahg: For future note, kreuter is upstream+Debian maintainer, so if you run into issues with mongodb in the future, he can probably make sure we don't need much divergence. | 16:26 |
| kreuter | I'm not the debian maintainer. | 16:26 |
| kreuter | Antonin Kral is. | 16:26 |
| persia | kreuter: You're not? You're listed as "Maintainer" in the diff in the bug. | 16:27 |
| micahg | persia: I'll subscribe myself to the package in case there are xul issues | 16:27 |
| kreuter | persia: that's because we (10gen) make debian packages too, and so we need something there in the upstream control file. | 16:27 |
| persia | Ah, it all makes sense now. | 16:27 |
| persia | micahg: Cool. Thanks. | 16:28 |
| kreuter | micahg: AFAIK, there are no xulrunner issues, just that 1.9.1 got deprecated very recently. | 16:28 |
| micahg | kreuter: we dropped it from Lucid | 16:28 |
| micahg | kreuter: in ubuntu we havn't had mozjs since xulrunner-1.8 though | 16:28 |
| === bdrung is now known as bdrung_home | ||
| === keffie_jayx_ is now known as effie_jayx | ||
| Laney | matttbe: is the package alright now? | 16:47 |
| === zz_nobawk is now known as nobawk | ||
| === traveller__ is now known as traveller | ||
| ari-tczew | does cdbs require a series file? | 18:42 |
| geser | ari-tczew: the simple cdbs patch system? no, it applies them in lexicographic order (series is part of quilt) | 18:45 |
| ari-tczew | thanks! | 18:45 |
| persia | Note that many CDBS packages use quilt. | 18:45 |
| geser | but you can use cdbs (the packaging style) with quilt | 18:45 |
| ari-tczew | I'm checking patch system by $ what-patch | 18:46 |
| geser | then cdbs is the "simple-patch" patching system from cdbs | 18:46 |
| samgee | I'm trying to make some sense of apt/repo terminology. It seems that debian and ubuntu use suite and codename differently. Is there any glossary explaining this stuff? | 18:51 |
| persia | samgee: How do you find them different? I don't pretend a perfect understanding, but I thought the terminology was the same. | 18:52 |
| samgee | persia, I read somewhere that debian uses codename as the development codename and when it releases it should be known by its suite name (stable, testing, ...). Ubuntu seems to use codename for the whole release (hardy) and suite for the "sub-releases" (hardy-updates). | 18:58 |
| persia | Ah, OK. | 18:59 |
| persia | So codename/release name is handled the same. | 18:59 |
| persia | So, Debian lenny became Debian 5.0 on release, and Ubuntu karmic became Ubuntu 9.10 on release. | 19:00 |
| samgee | well, that's yet another way of looking at it | 19:00 |
| persia | The difference in suite handling exists: Ubuntu has spearate suites for updates, whereas debian has -proposed-updates which get folded into the release directly. | 19:01 |
| === yofel_ is now known as yofel | ||
| geser | samgee: I know only of the LP API documentation, and it's also mentioned on the +queue pages (and probably others) | 19:11 |
| persia | samgee: And if this doesn't make it clear: you really don't need to know the answers to use the tools :) | 19:11 |
| samgee | persia, I know, but I'm working on a script to handle a repo and I'd like it be understandable by everybody, so I want to use the common terms | 19:13 |
| persia | Ah, this makes more sense. You might look at some other scripts (falcon, reprepro, launchpad, dak, mini-dinstall, etc.) to see if you can crib from there. | 19:14 |
| samgee | I've looked at some python-apt source code and other code/docs. There seems to be a lot of confusion about it. | 19:14 |
| samgee | searching web for ubuntu+codename+suite+pocket doesn't give much useful results. There's lots of stuff you can apparently stick in your pocket, though. :) | 19:18 |
| carstenh | samgee: in debian dak (from an external view, internal things are more complicated), the tool that does everything that is related to the archive, decides to which "suite" it moves your package depending on the changelog entry, though there are exceptions, e.g. there is no stable-security subdirecctory under dists. | 19:19 |
| carstenh | samgee: http://www.debian.org/doc/developers-reference/pkgs.html#distribution | 19:22 |
| samgee | carstenh, that's more of an explanation about what it's for. I'm looking for a simple explanation about what it is. | 19:22 |
| mdeslaur | ScottK: I have a bug fix for sbuild, is universe frozen now? Can I upload it? | 19:26 |
| ScottK | mdeslaur: Upload away | 19:26 |
| mdeslaur | thanks ScottK | 19:26 |
| carstenh | samgee: oldstable is the former release, stable is the current release, testing is the next release, unstable contains packages that move to testing when there are no problems with them after normally 10 days, experimental contains experimental stuff that is not ready for unstable, *-proposed-updates are packages that are proposed by a debian developer for inclusion in the distribution, which release manager decide | 19:27 |
| carstenh | samgee: but i guess i still don't understand your question :) | 19:28 |
| carstenh | (and the releasenames are symlinks pointing to oldstable, stable and so on, changing these is called releasing ;)) | 19:31 |
| samgee | carstenh, I'm looking for a definition of codename and suite that my mother would understand. | 19:31 |
| geser | ScottK: I plan to do an upload of ubuntu-dev-tools to update the defaults for maverick. But trunk contains also a new script (syncpackage). Should I seperate the changes and do only an upload for the changed defaults or go for a FFe (because of the new script)? | 19:31 |
| ScottK | geser: I'd prefer an upload without the script. I think we haven't fully digested the policy implicaitions of its widespread use. | 19:32 |
| samgee | e.g. Codename = the working name of a distro's release, like the army has working names like "Project Hide and Seek". | 19:33 |
| carstenh | samgee: finding one that your mother understands and that is also correct seems to be hard :/ | 19:33 |
| samgee | carstenh, your explanation about oldstable and such only applies to debian | 19:34 |
| persia | geser: Would you mind including the pbuilder-dist fix if you're rebasing? I'd really like to see that in lucid. | 19:36 |
| carstenh | samgee: ubuntu didn't reinvent the (or better this) whell | 19:37 |
| samgee | it's strange that debian (or ubuntu) haven't defined these terms in some manual. Doesn't that make conversations about repo and package handling hard? | 19:37 |
| geser | persia: yes, I planned to only take the syncpackage script out from this upload | 19:37 |
| persia | Those convesations don't tend to happen much. Generally folks just use software that does it for them. | 19:37 |
| persia | geser: Cool, thanks. | 19:37 |
| persia | re: syncpackage: didn't we remove pitti's script that worked like that from u-d-t? | 19:40 |
| persia | (plus getting Soyuz to handle native-source-sync is the right way, and that already (almost) works for PPAs) | 19:40 |
| geser | persia: the syncpackage script in u-d-t trunk is based on pitti's script | 19:41 |
| persia | Ah. I thought it was there before and then removed. I may be confused. | 19:42 |
| geser | I didn't check the history, so I don't know (and I don't remember it but that doesn't mean much) | 19:42 |
| ScottK | It's never been in there before, AFAIK | 19:43 |
| persia | Probably me misrememnering then. My memory of it being around was from around gutsy release, and after this much time, that is inherently suspicious. | 19:43 |
| ajmitch | morning | 20:02 |
| ScottK | mdeslaur: Nice bug. It's accepted. | 20:04 |
| mdeslaur | thanks ScottK :) | 20:05 |
| ScottK | mdeslaur: Does that affect versions in previous releases (i.e. should it be considered for SRU)? | 20:06 |
| mdeslaur | ScottK: oh! how odd, it probably affects karmic too | 20:07 |
| kamalm | persia: ping | 20:07 |
| mdeslaur | ScottK: I'll investigate and open a proper bug tomorrow if it affects older releases | 20:07 |
| ScottK | I think it's worth a look. | 20:08 |
| ScottK | Thanks. | 20:08 |
| mdeslaur | ScottK: although I've used sbuild everyday, I just hit the bug now, so I thought it was lucid specific! | 20:08 |
| ScottK | I've no idea. | 20:08 |
| persia | kamalm: Hey. Just going through some sponsoring, and I noticed the libticables2 bit was still listed as available to be sponsored. Do you happen to know the current status of the libti* mess? I'd like to just sort it all at once. | 20:08 |
| ScottK | It seems like you'd only trip it if you were low on space or had little installed. | 20:08 |
| kamalm | persia: gosh, its been awhile... let me dust off the cobwebs from my notes here. | 20:09 |
| ScottK | persia: AFAIK the status is needs sorting. It's been on my TODO for quite some time and never made it to the top. | 20:09 |
| ScottK | persia: It would also help with package installability. | 20:10 |
| persia | mdeslaur: ScottK: The bug is likely to affect more karmic users, as best-practice for karmic was small-size LVM volume for schroots, whereas in lucid it's to use directory chroots. | 20:10 |
| persia | kamalm: Thanks. I just want to make sure I'm starting from where you left off, rather than from scratch again. | 20:10 |
| mdeslaur | persia: I just started hitting it when I migrated to directory chroots :P | 20:11 |
| persia | Oh, hrm. I wonder if it's a tmpfs-size thing for the overlay. | 20:11 |
| geser | anyone familiar with bzr knows how to temporarily "revert" a commit from the past (not the last commit)? | 20:16 |
| ajmitch | the hacky way is to get the diff of that revision & its parent, and patch -R | 20:18 |
| ajmitch | there must be a better way to do it though | 20:18 |
| geser | ScottK: would it be acceptable to have the script in the source but not installed in the deb? I'm still trying to figure out how to do it best without disturbing the branch history to much | 20:19 |
| ScottK | geser: That's fine. | 20:20 |
| kamalm | persia: status of libti*2 --> libti*: libticalcs2 and libtifiles2 got merged and uploaded. my libticables2 merge does still need a sponsor: https://code.launchpad.net/~kamalmostafa/ubuntu/lucid/libticables/merge-526694 . (maybe you knew all that already) | 20:20 |
| persia | kamalm: Thanks for checking. That matched my memory, but I figured you'd know it better :) I'll take a look at ticables right after I finish the current one. | 20:22 |
| persia | (but it might be couple hours, as I've some time constraints coming up soon) | 20:22 |
| kamalm | persia: ok very good -- i'll be available whenever, if you need me | 20:22 |
| persia | kamalm: Thanks. | 20:23 |
| persia | Anyone have any handy scripts that do something like dget/dput over ssh? | 20:36 |
| ScottK | persia: I think dput supports it directly now. | 20:39 |
| persia | I thought dput did sftp | 20:40 |
| ScottK | (I'm not sure if that actually addresses your question) | 20:40 |
| ScottK | Ah, maybe it does | 20:40 |
| soren | persia: It does scp, sftp and rsync. | 20:40 |
| soren | persia: (and others) | 20:40 |
| persia | Not really, no. I've started using debsign -r and liking it, except for the bit that it makes uploading annoying. | 20:40 |
| persia | soren: But only to dput.cf locations :) | 20:40 |
| soren | persia: Uh... Yes? Where do you need it from? | 20:41 |
| * persia may write a tool that parses .dsc and .changes files and then does scp in one direction or the other. | 20:41 | |
| micahg | I have a silly question, if it's all open source, why would dput need to be over ssh? | 20:42 |
| ScottK | micahg: I don't see the relationship between those two points. | 20:42 |
| micahg | what needs to be protected in the upload I guess is my question | 20:43 |
| persia | soren: Mostly just to/from other local servers (potentially different architectures). | 20:43 |
| persia | micahg: I don't want to run an ftp server? | 20:43 |
| ScottK | So using sftp avoids a security risk. | 20:44 |
| micahg | persia: ah, for your own build server? | 20:44 |
| ScottK | Also not all Debian archives are public and have purely free software in them. | 20:44 |
| soren | persia: Oh, you want to take the stuff from somewhere else and put it somewhere entirely different? | 20:44 |
| micahg | ok, makes sense, thanks ScottK and persia | 20:44 |
| persia | micahg: Well, my own development servers. I'm not so organised that I have a complex wanna-build system: I just like to test-build on multiple architectures easily, regardless of where I'm doing the development. | 20:45 |
| persia | soren: I'd like to be able to operate on stuff in a manner similar to how debsign works: pass it a host:path parameter and have it pull or push sources/binaries as appropriate. | 20:45 |
| soren | Ok, got it. | 20:46 |
| persia | RIght now I have to list multiple files, and the set of dependent files is already encoded in the one file. | 20:46 |
| persia | Anyway, if nobody has one, it's not terribly difficult, and the debsign code probably contains 90% of what I need. I'll stick it in u-d-t for maverick if it works well enough for me. | 20:47 |
| ScottK | It doesn't sound Ubuntu specfic though. | 20:48 |
| persia | Hrm. I suppose I could submit it to devscripts. | 20:49 |
| * persia should probably stop hacking u-d-t anyway, and focus on other places, as nothing added so far is especially ubuntu-specific | 20:49 | |
| * jdong wonders how to generate those tree ring graphs without coding something entirely. | 20:53 | |
| jdong | trying to visualize fragmentation on my system | 20:53 |
| jdong | something along the lines of http://www.newfreedownloads.com/imgs/32486-w520.jpg | 20:54 |
| micahg | jdong: will it run in Wine? | 20:54 |
| jdong | micahg: haha I don't know what I'm gonna use to generate the graph yet. | 20:55 |
| jdong | I just need a number line wrapped in a polar coordinate system basically | 20:55 |
| === hannesw_ is now known as hannesw | ||
| ScottK | bdrung: I'm looking at your audacious-plugins upload. I may be reading this wrong, but it looks to me like your audacious upload renamed the icon to audacious, but at least one part of this patch is to look for audacious2? | 21:35 |
| bdrung | ScottK: which part? | 21:41 |
| ScottK | Just a moment, let me dig it up again. | 21:42 |
| ScottK | bdrung: In audacious-plugins-2.3/debian/patches/correct-icon-name.patch, the hunk starting at line 60. | 21:44 |
| bdrung | ScottK: didn't i drop this patch? | 21:46 |
| ScottK | bdrung: You did. | 21:46 |
| ScottK | Sorry, I was misreading the diff. | 21:46 |
| ScottK | Reading diffs of patches gives me no end of grief. | 21:47 |
| highvoltage | I can imagine that there are more fun things to do. | 21:47 |
| bdrung | diffs of diffs are not easy to read | 21:47 |
| persia | Just be sure to stay away from "derived" packages, where we can end up with diffs of diffs of diffs. | 21:49 |
| dutchie | and don't get highlighted in launchpad properly cough bug 553642 | 21:49 |
| ubottu | Launchpad bug 553642 in launchpad-code "Incorrect display of diff lines starting with +++" [Medium,Triaged] https://launchpad.net/bugs/553642 | 21:49 |
| bdrung | persia: it would be possible with eclipse ;) in the source tarballs are patches. now we modify the patches in the debian package and create a debdiff :P | 21:50 |
| persia | Right. That's the class of "derived" package that is annoying. openoffice.org is another example. This is annoyingly common also for everything that has licenses that require changes to be distributed as patches. | 21:51 |
| YokoZar | ScottK: done (wine) | 22:46 |
| ScottK | OK. I'll take a look at it in a bit. | 22:47 |
| YokoZar | ScottK: after wine then comes the ubuntu-studio dependent package, so there'll be another there | 23:01 |
| === highvolt1ge is now known as highvoltage | ||
| === keffie_jayx_ is now known as effie_jayx | ||
| ScottK | YokoZar: Looking at https://launchpad.net/ubuntu/+archive/primary/+files/qemu-kvm_0.12.3+noroms-0ubuntu6_0.12.3+noroms-0ubuntu8.diff.gz, I'm wondering if your wine upload is correct? | 23:24 |
| YokoZar | ScottK: I'd say the KVM upload is wrong. Keybuk could tell you more but I was told to use start procps. The || true also needs to be added to the KVM upload or the package may fail to install https://bugs.launchpad.net/ubuntu/+source/wine/+bug/447197 | 23:26 |
| ubottu | Ubuntu bug 447197 in wine1.2 "Packages with custom /etc/sysctl.d/30-foo.conf files can fail to install: start procps returns exit status 1" [Undecided,Fix released] | 23:26 |
| persia | In an upstart-only world, "start procps" is correct, but I'm unsure that packages are supposed to assume that. | 23:27 |
| YokoZar | ScottK: I had a bit of a spat with Keybuk over this but the long and short is that both start procps and invoke-rc.d will fail when there's something wrong in /etc/sysctl.d rather than give a warning -- and somehow people were getting something wrong there without modifying it by hand. | 23:27 |
| YokoZar | persia: I think it's a safe assumption when procps is in upstart (but not everything else is). If you look at the upstart job it's basically the same code anyway. | 23:28 |
| * persia suspects that assumption of an upstart-only world would require a policy deviation from Debian | 23:28 | |
| YokoZar | persia: or rather mixing upstart and non-upstart invokes shouldn't be a bad thing | 23:28 |
| YokoZar | Let's ask keybuk | 23:28 |
| persia | YokoZar: If it's "basically", something is wrong. invoke-rc.d should be upstart-aware, and call the right job. | 23:28 |
| YokoZar | It was months ago that I looked at it to be honest. Either way the important part was the || true at the end | 23:29 |
| persia | I'm in strong support of || true :) I just happen to agree with lool's interpretation of policy. | 23:29 |
| YokoZar | Also I'll note the documentation is out of date (that says packages need to use rc.d instead of start) | 23:30 |
| YokoZar | In fact I think that's mentioned at the bug I linked | 23:30 |
| YokoZar | Here's keybuk in the bug report: "start procps" is the right command | 23:32 |
| lool | YokoZar: start procps would work in e.g. chroots which have a policy-rc.d in place | 23:32 |
| lool | Currently, there's no policy compliant way to disable upstart jobs directly, policy-rc.d is only honored if you use invoke-rc.d | 23:32 |
| YokoZar | lool: so we should use start procps then? | 23:33 |
| lool | YokoZar: No, we should not | 23:33 |
| lool | ScottK, persia: ^ | 23:33 |
| lool | YokoZar: invoke-rc.d will check and honor policy-rc.d | 23:33 |
| lool | and will ultimately do the same thing as start procps if it's enabled | 23:34 |
| YokoZar | In that case I'll need to switch to invoke-rc.d in both wine and wine1.2, and then bother keybuk again | 23:34 |
| lool | YokoZar: where did kyebuk comment on start procps being the right thing? | 23:34 |
| YokoZar | lool: I still need invoke-rc.d ... || true of course | 23:34 |
| lool | YokoZar: start procps is noisy only when run manually | 23:34 |
| lool | YokoZar: Yes | 23:34 |
| lool | But not when run from dpkg | 23:34 |
| lool | So that should be fine | 23:34 |
| lool | I mean invoke-rc.d is noisy, sorry | 23:34 |
| YokoZar | lool: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/447197/comments/12 | 23:34 |
| ubottu | Ubuntu bug 447197 in wine1.2 "Packages with custom /etc/sysctl.d/30-foo.conf files can fail to install: start procps returns exit status 1" [Undecided,Fix released] | 23:34 |
| persia | qemu-kvm would probably benefit from || true as well | 23:34 |
| YokoZar | persia: Yes, otherwise you're going to have a whole lot of upgrade failures | 23:37 |
| lool | YokoZar: Commented in there | 23:37 |
| lool | persia: Yes, albeit I'm not really tempted to touch that | 23:37 |
| * lool is tired now | 23:38 | |
| * lool & | 23:38 | |
| persia | heh, OK. | 23:38 |
| ScottK | YokoZar: What was the conclusion? | 23:49 |
| YokoZar | ScottK: I think lool convinced me and we should do: invoke-rc.d procps start || true for wine, wine1.2, and qemu-kvm | 23:51 |
| ScottK | YokoZar: So I shold reject this wine upload. | 23:51 |
| YokoZar | ScottK: sure | 23:52 |
| ScottK | OK. Done. | 23:52 |
| ScottK | Reupload when you're ready and I'll have another look. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
