RAOFachiang: Pong00:07
jturek_whoohoo thanks for fixing emacs  gtk in maverick guys :)00:58
RAOFWell, not so much fixed as had the GTK patch that was breaking it dropped.01:00
jturek_(catching up on the launchpad bug report now)01:00
ajmitchby breaking it, you mean the spam on the console?01:00
jturek_ajmitch, lp bug 58519601:01
ubottuLaunchpad bug 585196 in emacs23 (Ubuntu Maverick) "emacs fails to start: X protocol error" [Undecided,Confirmed] https://launchpad.net/bugs/58519601:01
RAOFNo, the BadMatch error as soon as emacs tried to display a window.01:01
ajmitchah, shame01:01
jturek_not admitting i am an emacs addict or anything ;)01:01
RAOFThe spam on the console is a theme issue.01:01
RAOFAt least, I think it is.01:02
ajmitchbug 538499 is the one I was thinking of01:02
ubottuLaunchpad bug 538499 in light-themes (Ubuntu) "warning spam on stdout: CRITICAL **: murrine_style_draw_box_gap: assertion `height >= -1' failed" [Medium,Triaged] https://launchpad.net/bugs/53849901:02
jturek_thanks ubottu ;)01:02
m3gaerr, where is Xorg.conf in lucid?01:38
m3gait should be /etc/X11/xorg.conf shouldn't it?01:39
=== funkyHat is now known as funkyWhat
RAOFIf you've got one; you probably don't.01:40
m3galifeless: yea, thats what i expectedi don't01:41
m3gaRAOF: no it don't01:41
m3gashould i have?01:41
m3gaok, so how do i bash xorg round the head to use my mouse device?01:42
RAOFYou can create an xorg.conf and add just a Device section.  I still think that if the kernel isn't presenting it as an input device you're likely to be out of luck.01:42
m3gakernel finds this : input: AVAGO TECHNOLOGIES AVAGO USB OFN Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/input/input401:43
m3gageneric-usb 0003:192F:0000.0001: input,hiddev96,hidraw0: USB HID v1.01 Mouse [AVAGO TECHNOLOGIES AVAGO USB OFN Device] on usb-0000:00:1a.1-1/input001:44
=== funkyWhat is now known as funkyHat
=== freeflyi1g is now known as freeflying
=== Amaranth_ is now known as Amaranth
=== sconklin-gone is now known as sconklin
=== jdong_ is now known as jdong
=== 5EXAAYM9J is now known as temugen
=== sconklin is now known as sconklin-gone
nigelbjcastro: a bit too late, but I haven't logged into this session for a while05:18
nigelbDon't unsubscribe reviewers team after a review is done, it helps for statistical purposes05:19
dholbachgood morning07:52
=== hrw|gone is now known as hrw
=== almaisan-away is now known as al-maisan
pittiGood morning08:28
ddecatormorning pitti08:28
pittihello ddecator08:29
* pitti finsihes a new-binary-debian-universe run to clean up NEW somewhat08:52
pittiseb128: d-conf NEWed as well, in case you are waiting for it08:59
pittiand the new kernel08:59
seb128pitti, oh, thanks09:01
seb128pitti, I newed it but it was only built on amd64 the other day when I did I think09:01
ricotzpitti, hello, i want to ask about the pending docky sru in lucid-proposed09:09
ubottuLaunchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed]09:10
pittiricotz: it fixes 19 bugs, but none got any feedback so far09:10
pittiugh, who accepted that?09:11
ricotzpitti, there are feedbacks on the bug reports itself09:11
pittiRiddell: did you accept docky into lucid-proposed?09:11
pittinone of them have ubuntu tasks, or are set up for SRU09:11
pittiricotz: I opened a sample of 4 bugs, and none of them have an "please test the SRU" question or even a SRU request09:12
pittiand feedback about the lucid-proposed version09:12
ubottuLaunchpad bug 555562 in docky (Ubuntu Lucid) "crash accessing Gnome keyring in Lucid" [Critical,Triaged]09:13
pittiricotz: ok, I marked that one as verified; 1 down, 18 to go..09:14
pittiwell, we probably don't need all 18, but for an update as big as this we need much more than "1"09:14
ricotzpitti, like i wrote in my comment on the sru bug, it is impossible to get all reports09:14
ricotzi have linked some comments here https://bugs.edge.launchpad.net/docky/+bug/574003/comments/909:15
ubottuLaunchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed]09:15
pittibut at least the bugs should have ubuntu tasks, tell the maverick status, and ask people to check the lucid-proposed version09:15
pittiricotz: ok, I'll mark those as verified09:16
LaneyI don't know who set it up for an SRU, but when I did the previous version I made sure to open all Lucid tasks09:16
pittiexcept that they didn't actually test the ubuntu package09:17
pittisince by that time it wasn't even in the package09:17
pittiricotz: ^09:17
pittifolks apparently tried some vcs head snapshot or so?09:17
ricotzpitti, yes, like i wrote in my comment, we backport commits to the stable branch, if there are regressions they should prevent the inclusion while there are so many bugs fixed09:19
ricotzdocky 2.0.2 is from the current view very broken and is not able to please peoples needs in some ways therefore they perhaps stop using it09:20
pittithat's why we usually ask for testing the proposed package in all the bugs09:21
pittiwhich will reach the bug reporters09:21
pittiI can do that with a script09:22
pittibut it should never have been accepted this way in the first place09:22
ricotzyes, but in this case most of the reporters would have switched to the ppa in the meantime09:22
pittiso they could switch back..09:23
ricotzthis is unlikely cause there were major packaging changes and new dependencies for upcoming 2.1.009:24
ricotzi understand your point to verify these bugfixes, but it also hard for us to get confirmation for more recently reported bugs09:25
pittiricotz: hm, the changelog doesn't even mention bug 57400309:25
ubottuLaunchpad bug 574003 in docky (Ubuntu Lucid) "Clock context menu not indicating state of options" [Medium,Fix committed] https://launchpad.net/bugs/57400309:25
pittiricotz: oh, I'm not primarily blaming you; it's just that the current state of this SRU is so poor (how it was accepted and the bugs prepared) that it will have a very low chance of being tested09:26
pittiricotz: ok, I'm sending out calls for testing to the bugs09:27
ricotzthis bug should be in the changlog for 2.0.309:27
Laneyit wasn't uploaded with -v09:28
pittiso it should be fixed in maverick09:28
pitti(there are no ubuntu tasks to keep track of the state)09:29
pittiso, let's see whether we'll get some responses09:29
pittiricotz: I also subscribed ubuntu-sru to all the bugs09:29
ricotzpitti, thank you09:29
pittibut whoever accepted this, please don't in the future; it's causing a lot of extra work09:29
ricotzpitti, on the other hand, it is a bit unpleasant for upstream devs who do spend a lot of work to maintaining a stable release besides a development branch, it seems hard to get an sru for an application like docky which has no rdeps09:33
pittiricotz: no, not really; it just takes some care to prepare the bugs accordingly (not necessarily by you)09:33
ricotzperhaps packages could be categorized to make a sru easier for universe one?09:33
pittiricotz: the actual changes seem quite appropriate for an SRU09:33
pittiit's just that due to the way the SRU was handled, we would not get any feedback09:34
pittiand the SRU team didn't even know about this, since they weren't subscribed to any of those09:34
pittiwe put new upstream microversions into LTSes all the time09:35
ricotzok, but a least this one bug was subscribed to the sru team, alright09:35
ricotzpitti, i am trying to push this a bit, cause i am planning to release docky 2.0.5 very soon09:36
pittiricotz: once we get a handful of testing on the proposed package, we can move it09:37
ricotzpitti, thank you, i hope the will be some responses soon09:38
apwwith the new debian 3.0 formats available do we have a feeling on whether we are keen for existing packages to migrate to it or not ?09:42
pittithere's no particular hurry, I think09:43
apwpitti, is it recommended?09:43
pittiwe should certainly start doing new packages that way09:43
pittiand once we touch a package anyway, and you feel like it, you can as well do it09:43
pittibut I wouldn't touch packages just for that09:44
apwpitti, thinking about the kernel where we are obviously touching them most of the time09:44
pittiapw: that sounds rather easy, given that you don't actually use orig.tar.gz's and patches for that, right?09:44
apwpitti, we do use origin.tar.gz's against the upstream version yes once released of course09:45
apwi have prototyped it with the 3.0 (quilt) format which looks to work but trying to work out where it is available09:45
pittiapw: but then you'd need to do proper patches instead of changing inline, which is what you tried to avoid, I thought?09:45
apwpitti, seems that in that mode any diff from the tarball to 'here' is turned into an automatic patch for you09:46
apwso i think it works fine for us09:46
pittiapw: it's the other way around09:46
pittiapw: debian/patches/* is automatically applied to the source on unpack09:46
pittiall inline modifications to the upstream source are _ignored_ when building the source package09:47
pittiyou only have a debian.tar.gz09:47
apwright ... but on dbuild -S if you have an orig then it diffs everything but debian and makes a patch out of those and puts it in debian/patches, then it makes the debian tarball09:47
pittiapw: oh, I didn't know that09:47
pittihow do you do that?09:48
apwit just happens automatically09:48
pittiah, I see09:49
apwas far as i can tell it applied the patches in debian/patches, then diffs the result, and adds a new patch ... something like that09:49
pittiI actually don't like that at all, but seems to be that way09:49
pittiseems you'd still get weird patches with spurious config.guess stuff etc. that way09:50
apwpitti, yeah seems so ... as far as i can see the only real advantage is you get stuff in debian as you intended, zero length files and permission maintained09:50
pittiso it still doesn't obsolete the need for separate build-tree/09:51
apwpitti, no i think not09:51
apwpitti, actually it does say 'upstream paths' are diffed09:52
apwso perhaps its only the ones in the tarball not new files09:52
apwno that wouldn't work either09:52
pittino, I guess it'll do the whole thing09:52
pittiwith {bzr,git}-buildpackage you avoid this random clutter, so I stopped worrying about it long ago09:53
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== aronxu is now known as happyaron
cjwatsonapw: yeah, I don't know how useful 3.0 (quilt) is for you, unless you write something that automatically serialises the git tree into a set of quilt patches11:53
cjwatsonwhich might be an interesting and useful project, but doesn't seem terribly urgent :)11:53
cjwatson(I think somebody may have been working on something like that for git-buildpackage, not sure)11:54
apwcjwatson, in its basic form it seems usable as a replacement for orig/diff format in a similar way ... with the advantage that debian/* is correclty maintained permissions etc wise ... not sure if that enough of a reason to switch tho.11:55
cjwatsonapw: I don't think there's a great deal of point in using 3.0 (quilt) in the mode where you just have it automatically spit out a single patch11:55
cjwatsonpermissions and binaries and the like are I suppose mildly useful11:55
apwno unless 1.0 is going to go away11:55
cjwatsonit's not11:55
cjwatsonyou might want to declare 1.0 in debian/source/format if you're going to stick with it though11:55
apwyeah at least the archive knows i chose that way11:56
cjwatsondon't get me wrong, I think 3.0 (quilt) is fantastic and I use it for all my packages, but I think that's more the case if you actually use it for maintenance work rather than just have the package spat out that way automatically11:56
cjwatsonwell, all my packages that aren't 3.0 (native) anyway :-)11:57
apwyeah i can see that, if there is no advantage to switching to that mode for the archive, i suspect there is little for us11:57
cjwatsonhttp://upsilon.cc/~zack/stuff/dpkg-v3/ <- graph of 3.0 format adoption in Debian11:58
=== MacSlow is now known as MacSlow|lunch
apwcjwatson, do you have any idea why one has to specific (native)/(quilt) given older formats could work it out ... just seems to make life difficult12:20
cjwatsonapw: it was actually often a problem that the older formats worked it out; it was quite common for people to upload native packages by accident when they'd actually just misnamed the .orig.tar.gz12:21
cjwatsonthe vast majority of packages don't intend to switch back and forward between native and non-native12:21
apwfair indeed12:22
buxypitti: clean is supposed to remove clutter so that they don't end up in automatic patches, and now you can also stick supplementary files to ignore in debian/source/options with --extend-diff-ignore12:48
pittibuxy: ah, --extend-diff-ignore sounds nice12:48
pittibuxy: right, but some packages do really nasty stuff like updating config.guess in the clean target12:49
pittiunfortunately this used to be in the dh-make template12:49
pittibut well, I disgress..12:49
buxyI know, recommendations have changed over time but many are still polluting the diff due to that12:50
seb128you often have no easy way to clean12:50
seb128like if you run autoreconf at build time12:50
pittifor those, bzr bd or git-buildpackage just DTRT12:51
buxyseb128: there's dh-autoreconf (for dh7/cdbs) but I'm not sure I like it12:52
buxy(i.e. it's somewhat overkill for the purpose)12:52
pittidoes anyone see what I'm doing wrong here? apt-get source -o DPkg::options::="--require-valid-signature" pmount   -> --require-valid-signature is never passed to dpkg-source12:53
buxypitti: I think Dpkg::options:: is only for "dpkg" not dpkg-source12:53
sorenpitti: You can tweak Dir::Bin::dpkg-source instead.13:05
sorenpitti: change it to "dpkg-source --require-valid-signature" and you should be fine.13:05
pittisoren: to point to a locally modified dpkg-source13:05
pittisoren: ah, nice13:05
sorenpitti: No, just pass the extra arguments.13:05
sorenIt's concatenated with "-x blah.dsc" and passed to system.13:05
sorensystem(3), that is.13:06
=== MacSlow|lunch is now known as MacSlow
=== zyga is now known as zyga_away
apwpitti, did i ask you about the apparent leakage of red and green out of the top of our bars on the burn-down charts for A2 ?13:50
pittiapw: you didn't14:14
pittiindeed, looks weird14:14
pittiapw: perhaps it's related to the bug I'm currently chasing14:14
pittiI've been getting tons of ZeroDivisionError exceptions from cron14:14
pittibut whenever ran the damn thing by hand it of course worked14:14
pittiso I added some extra debugging, but never got a cron mail since then :-/14:15
apwhrm, thats a bit mad, does it fail if you run it via at ?14:15
pittiit started perhaps a week ago, so something in the data must have changed14:15
pittiapw: haven't tried14:15
pittithe other reports (a3, entire cycle) seem to look just fine14:16
pittiso it seems that's the one which might upset it14:16
apwpitti, fyi its the same in firefox and chromium so i assume its real14:16
pittiyes, I don't think it's an svg problem; it's somewhere in pychart14:17
pittiapw: I'll keep that on my radar; I take it it's not OMGblocking you?14:17
apwno not at all, its just an oddity14:17
apwpitti, one which seems familiar ... i have the feeling its been about before and gone away14:18
pittiapw: also, it looks alright again from June 14 on, which could be about the time when I added the debugging stuff14:19
apwpitti, somewhat peculiarly it seems to have sorted itself in the last 4 days results14:19
apwbut arn't the whole report rebuilt each time14:19
pittiyes, it is14:20
pittiI removed the debugging stuff again14:20
apwso it must still be in the old data somehow ... hrm14:20
pittilet's see whether it fails again next time14:20
apwso one assumes the issue is collector side not reporter perhaps14:20
pittiapw: or if the chart data has a particular shape, like bunny ears for example14:22
=== sconklin-gone is now known as sconklin
=== njpatel_ is now known as njpatel
=== aronxu is now known as happyaron
apwcan anyone point me to the i686/cmov discussion so i can confirm we are in line with it15:26
apwcjwatson, ^^15:30
cjwatsonapw: foundations-m-686-compile, but it's waiting for doko to write it up15:32
apwcjwatson, ahh yes thanks ... so we shouldn't be reacting kernel wise as yet then15:33
cjwatsonthere's probably an audio file of the UDS session if you're desperate :-)15:33
apwcjwatson, heh no not desperate, just wondering if we should be doing somethign for maverick.  but seening as there isn't even a uds write up for it, i suspect doing anything is pre-emptive15:34
apwcjwatson, there don't seem to be any work-items on that spec which is concerning given it implies a rebuild does it not?15:38
cjwatsonapw: we're not going to rebuild everything just for that, no15:42
dokocjwatson: yes, still to write :-/15:42
zulcan someone from the foundations team review the upstart job: https://bugs.edge.launchpad.net/ubuntu/+source/tgt/+bug/57455415:45
ubottuLaunchpad bug 574554 in tgt (Ubuntu Maverick) "tgtd needs init script or upstart job" [Medium,Triaged]15:45
apwdoko, was a definative decision made?  there seems to be some feedback requests on there ...15:46
dokoapw: about what?15:48
apwdoko, about which options we were going to require for that blueprint15:49
dokoapw: "options to require?"15:50
apwdoko, did we determine the minimum required cpu features we would support going forward, under the auspecis of the blueprint: foundations-m-686-compil15:52
=== bladernr is now known as bladernr-afk
dokoapw: yes, i686. but I didn't look at the nop problem yet, if it's just a glibc local thing, or if this is seen generally)15:55
smoserRiddell, "ebsmount upload of the day" is ready.  i ran 'licensecheck' this time. sorry for not having done that before.16:12
Riddellsmoser: upstream did another new release?16:13
smoserwell, sort of.16:15
smoserthose files didn't come from upstream, but from another turnkey project. they ammended the turnkey-pylib files (which i had copied)... i mentione dthis in a mail yesterday.  those files were written by debian/patches.16:15
smoserRiddell, ^16:18
Riddellsmoser: and that turnkey-pylib project has files which say they're GPL and not "all rights reserved"?16:19
smosercorrect.  the patch references the git repo and commit level16:20
Riddellsmoser: lovely, accepting16:21
smoserthanks for your time Riddell16:23
=== bladernr-afk is now known as bladernr
=== bladernr is now known as bladernr_
kirklandpitti: ping16:56
pittihey kirkland, how are you?16:56
kirklandpitti: not bad :-)16:57
kirklandpitti: who's handling SRUs in your place now?16:57
kirklandpitti: i wanted to see about getting https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=qemu-kvm accepted to lucid-proposed16:57
pittikirkland: it's in between cjwatson, slangasek, and me16:57
pittijdong and ScottK help out as well16:58
ScottK(all I can do is hit the accept button on stuff jdong has approved)16:58
kirklandpitti: cool, thanks16:58
jdongACKed :)17:02
ogasawaradoko: do you have an ETA for when you'll have the foundations-m-686-compile spec written up.  I'm the one with the Alpha2 work item assigned and if something needs to get into the Alpha2 kernel it needs to happen by mid next week.17:03
dokoogasawara: ok, will try to do it today17:04
ogasawaradoko: thanks17:04
dokoogasawara: I thought you already did drop the i386 variant17:04
ogasawaradoko: we did17:04
pittimr_pouit: same question for exo; it can use gio as well now, so I'd drop the build/binary hal depends17:09
pittimr_pouit: I have both exo and thunar prepared now, and working great17:09
=== beuno is now known as beuno-lunch
=== awolfson is now known as awolfson_lunch
=== MacSlow is now known as MacSlow|capoeira
ScottKkirkland: Accepted.17:21
pittimr_pouit: I'm also uploading three packages to build against exo-1 instead of the exo-0.3, to avoid two ABIs; hope you don't mind?17:27
mr_pouitpitti: exo-1 isn't stable either...17:28
pittimr_pouit: ah, so you prefer stuff to be built against -0.3 for now?17:29
mr_pouitthunar(-gio) isn't ready at all17:29
mr_pouitit can't remember file associations for example17:29
mr_pouitand no volume auotmounting17:29
pittimr_pouit: I'm currently working on an automounting solution, FYI17:29
mr_pouityou should tell that to upstream then :)17:30
pittimr_pouit: but ok; I'll delete the xfce4-terminal transition from the xubuntu-dev PPA again, sorry about that then17:30
mr_pouitah in, the ppa ?17:30
mr_pouitfine then17:30
mr_pouitI thought in was for the archive17:30
pittinah, xubuntu-dev PPA17:30
pittiwhich has the new exo17:30
mr_pouityeah, so no problem17:30
pittimr_pouit: I have xfce4-{settings,terminal} for exo-1 (simple patch)17:31
mr_pouitxfce 4.8 will probably get delayed of several months, that's why I was a bit nervous if you wanted to upload that to maverick ;>17:31
pittimr_pouit: I could do it for our own project only, but from our POV it'd make more sense to work in the xubuntu-dev PPA and all work on the same stuff?17:31
pittibut your call, of course17:31
mr_pouitno no, the ppa is fine if it's easier for you17:32
pittiok, great17:32
pittimr_pouit: I updated https://wiki.ubuntu.com/Halsectomy a bit17:32
pittigreat to see progress on the XFCE side :)17:32
pittiand saves two seconds boot time17:32
mr_pouitpitti: fyi, the three panel plugins (volstatus, governor, cddrive) you put on the list are (more or less) unmaintained upstream, so it's very very low priority17:34
pittimr_pouit: "governor" is for CPU clock, I suppose?17:34
pittithere should be little reason to fiddle with this manually these days17:34
mr_pouityeah, I wanted to remove it from the archive, but some people complained ("it works, why remove it")17:35
kirklandScottK: jdong: thanks17:36
mr_pouitpitti: I'll try to complete a bit the halsectomy page, because some programs/plugins (e.g. xfce4-places-plugin) rely on libthunarvfs for {un,}mounting partitions, whereas other only for file management. So it's not obvious to know which ones need to be halsectomied without grepping the code.17:44
pittimr_pouit: libthunarvfs seems to be obsolete entirely, right?17:45
mr_pouitanyway, gtg, thanks for your work on that :)17:46
=== hrw is now known as hrw|gone
pittimr_pouit: thanks, enjoy17:47
=== al-maisan is now known as almaisan-away
* LucidFox wishes pbuilding GTK and Qt applications didn't involve installing half of X...17:55
=== beuno-lunch is now known as beuno
=== sconklin is now known as sconklin-lunch
cjwatsoncking: re https://wiki.canonical.com/ColinKing/EFIAndGrub2-IntelDevelopmentKit - I arranged for GRUB to read most of the kernel and initrd in one single EFI call today, and (to my surprise) it didn't actually improve the time perceptibly18:23
cjwatsoncking: this was reading from an iso9660 filesystem, so the files were contiguous18:24
cjwatsoncking: the only thought I have is that using the block I/O layer rather than the disk I/O layer would avoid some copies, but that requires GRUB to handle alignment itself - and I already avoided at least one full copy of the data by turning off disk caching and that didn't seem to make any difference18:25
cjwatsoncking: this was with OVMF under emulation, though18:26
cjwatsoncking: but it's interesting to hear that you had similar performance problems on bare metal18:26
cjwatsoncking: if you want to try my changes, they're here: http://paste.ubuntu.com/451197/18:27
=== deryck is now known as deryck[lunch]
=== sconklin-lunch is now known as sconklin
kirklandcjwatson: odd ...  running "status ssh" on my lucid box exits 0, prints nothing;  sshd is in fact running though18:49
kirklandcjwatson: maybe an upstart hiccup18:49
=== JanC_ is now known as JanC
=== deryck[lunch] is now known as deryck
=== yofel_ is now known as yofel
=== echidnaman is now known as JontheEchidna
=== awolfson_lunch is now known as awolfson
EtienneGQuestion: is there any way we can force installation of a restricted driver at install time, through preseeding?  Would invoking "jockey-text -e nvidia" as a late_command be sufficient?20:21
superm1EtienneG, a little more complicated, but this solution will work http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=ubuntu-fid.git;a=blob;f=framework/scripts/chroot-scripts/fish/01-jockey-drivers.py;h=6c693af7255f0fc21b6b5695906d2be52e9752cc;hb=HEAD21:30
superm1(if the rest of the env is setup right for the late command that is)21:31
EtienneGsuperm1, thanks a bunch21:33
smoserhey all, i have a python package that is dynamically loading modules, via __import__(modname). i'm wondering where would be the right place to put the modules in a package, and subsequently, how to look up that path in python21:37
smoserso far, i have found that uso far, module name 'a' is loading plugins.  i'm able to load them by sys.path.insert(0,a.__path__[0] + "/handlers")21:38
=== MacSlow|capoeira is now known as MacSlow
Sarvattlool: go figure binutils got uploaded *right* after your oprofile upload, needs a rebuild :)22:03
=== almaisan-away is now known as al-maisan
ScottKsmoser: I'd suggest ask for assistance in #debian-python on OFTC.22:15
=== al-maisan is now known as almaisan-away
hallynmathiaz: kirkland: process question.  It only just came to my attention that the lxc package is a straight debian package.  I'd like it updated to 0.7.0.  Do we (a) send email to the package maintainer requesting update, (b) create a debian bug to ask for it, (c) create our own temp 0.7.0 package, or (d) just wait patiently?22:33
mathiazhallyn: (d) is the prefered solution22:34
mathiazhallyn: depending on how important it is to get the new upstream version (c) is also possible22:35
mathiazhallyn: is there a specific blueprint or milestone target for lxc to be updated to 0.7.0?22:35
geserhallyn: depending on when the new upstream got released you could contact the DD and ask if he needs/wants help with the package22:36
hallynmathiaz: i'd be nice to have it for alpha2, so next week22:36
hallyn(it's in the blueprint, yes, and would just be nice)22:36
hallynnow 0.7.0 just came out today...22:37
hallynso i'm certainly being unreasonable, but still was wondering whether we usually try to email the DD or not22:37
hallyni'll wait a day or two, thanks22:37
loolSarvatt: Tss :-)22:37
loolSarvatt: uploaded22:38
hallyngeser: i assume you mean "if it's been a long time since the upstream release"22:38
geserhallyn: yes, something longer than a few hours :)22:39
hallyngeser: drat!22:40
hallynthanks :)22:40
mathiazhallyn: right - helping the DD is also welcome22:40
mathiazhallyn: you could look at the debian changelog and infer how responsive the DD is22:41
mathiazhallyn: you could also push a package to a PPA22:41
mathiazhallyn: to get more testing done22:41
hallynmathiaz: yup, i've got my own bzr branch (and package on its way to ppa) - bc man, the ubuntu lxc template works GREAT22:56
mathiazhallyn: \o/23:04
=== bjf is now known as bjf[afk]

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!