| === freeflyi1g is now known as freeflying | ||
| === jcastro_ is now known as jcastro | ||
| hallyn | qemu-kvm's bzr tree is out of sync with the package, ubuntu4 vs ubuntu8. Is it usually ok to just bzr import-dsc the ubuntu8, or should i be hunting down each intermediate .dsc? | 00:53 |
|---|---|---|
| jelmer | hallyn: my guess is that without the intermediate .dsc's the importer will move your branch out of the way later | 00:54 |
| hallyn | what do you mean, move it out of the way? | 00:55 |
| jelmer | hallyn: Sorry, I assumed you were talking about the UDD branch | 00:56 |
| hallyn | i was | 00:56 |
| hallyn | (i think :) | 00:56 |
| jelmer | hallyn: if you push to the UDD branch and the importer gets fixed and tries to import the new packages in the archive, then I suspect it will overwrite your changes to import the missing packages | 00:56 |
| jelmer | hallyn: and then create a merge proposal for your changes into the UDD branch | 00:57 |
| hallyn | hm, which i would think woudl be want i want, right? | 00:57 |
| jelmer | well, it depends on what you want :) | 00:57 |
| hallyn | i just want lp:ubuntu/qemu-kvm in sync so ppl can use UDD if they want | 00:58 |
| hallyn | i don't mind doing all the intermediate .dscs, i'm just not sure where to get them all | 00:58 |
| jelmer | my guess is that import-dsc wo't work for the intermediate .dsc's, as the importer uses the same code underneath | 00:58 |
| jelmer | if you just care about being able to do uploads for now, then importing the last dsc should be sufficient | 00:59 |
| jelmer | you might have to "bzr pull --overwrite" in the future though, when the importer is fixed | 00:59 |
| hallyn | cool, i'll give that a shot then, thanks jelmer! | 01:00 |
| === asac_ is now known as asac | ||
| lamont | http://paste.ubuntu.com/651565/ <-- I wonder if this apport bug is known | 04:05 |
| === dendro-afk is now known as dendrobates | ||
| didrocks | good morning | 05:19 |
| === dendrobates is now known as dendro-afk | ||
| dholbach | good morning | 06:48 |
| === smb` is now known as smb | ||
| === dendro-afk is now known as dendrobates | ||
| hrw | morning | 07:38 |
| Q-FUNK | two uploads (to maverick-proposed and lucid-proposed) of cups-pdf were rejected. would anyone be able to tell me why? | 08:20 |
| infinity | Q-FUNK: Automatic or manual rejections? | 08:21 |
| RAOF | Q-FUNK: I documented that on the bug, did I not? | 08:21 |
| Q-FUNK | RAOF: not that I could seee, no. | 08:21 |
| Q-FUNK | RAOF: or which bug number are you talking about? | 08:22 |
| RAOF | Q-FUNK: Which bug do you think I'm referring to? Perhaps I was confused as to which SRU bug they were expected to fix? | 08:22 |
| Q-FUNK | bug #805947 | 08:22 |
| ubottu | Launchpad bug 805947 in cups-pdf (Ubuntu Maverick) "SRU: hand-picked packaging fixes for Lucid and Maverick" [Undecided,New] https://launchpad.net/bugs/805947 | 08:22 |
| RAOF | Ah, ok. | 08:23 |
| Q-FUNK | I'm perhaps confused as to whether to where to put the LP bug number and which one, when it's an omnibus collection of fixes. | 08:23 |
| Q-FUNK | RAOF: I just noticed the one you were talking about. it might fix it too. | 08:24 |
| RAOF | Definitely *somewhere* in the changelog entry :) | 08:24 |
| RAOF | Because it wasn't clear what bug you were expecting to fix, I picked the LP bug from the most recent changelog entry. | 08:25 |
| Q-FUNK | RAOF: ok. how do I fix this one, then? I guess my main point of confusion is that I the fix applies to two releases, so I'm wondering how to manage that. | 08:25 |
| RAOF | Well, you'll make two separate uploads, which is fine. | 08:25 |
| infinity | Q-FUNK: You can close it twice, once in each upload. | 08:25 |
| infinity | Q-FUNK: And have two tasks for the bug, once for each release. | 08:26 |
| Q-FUNK | ok, so what about now? simply adding the LP bug number for the SRU and re-uploading as ~lucid2 ? | 08:26 |
| RAOF | Also, I don't think ‘here are some maintainer script changes you might want to pick up’ is a good SRU justification. We need some way of telling whether or not the packages have actually fixed the bug(s) they were intending to fix, and also some idea of whether the bugs have an appropriate risk/reward. | 08:27 |
| Q-FUNK | RAOF: it's the the changelog for 2.5.0-17squeeze1 | 08:28 |
| Q-FUNK | pitti even thought that my changelog entry there was a tad too verbose, when I asked him to review my delta. | 08:29 |
| RAOF | Ah. Has pitti commented on that SRU? | 08:29 |
| RAOF | Q-FUNK: If that's all that you want to pick up, then why are all the other changelog entries there? Maybe this is a mismatch on what's expected of an SRU. What we're looking for in an SRU is (a) a clear description of the problem, making it obvious that it's worth SRUing and how to tell that it's fixed and (b) a *minimal* patch to fix that bug. | 08:30 |
| Q-FUNK | RAOF: he reviewed my delta, but I don't think that he has commented in the bug. he was the one who recommended dropping that LFS support, for instance. | 08:30 |
| RAOF | Did he review your delta against Debian, against Oneiric, or against Lucid & Maverick? | 08:32 |
| Q-FUNK | lucid and maverick, both of which have 2.5.0 | 08:32 |
| Q-FUNK | oneirc has an entirely newer upstream. | 08:32 |
| Q-FUNK | actually, both natty and oneric have 2.5.1 | 08:32 |
| RAOF | Hm. And he suggested that the changelog was appropriate for an SRU? | 08:34 |
| infinity | The changelog is just detailing the packaging changes. | 08:34 |
| Q-FUNK | the one for 2.5.0-17squeeze1 seemed to satisfy him, but it might be a side-effect of being intimately familiar with anything CUPS-related. | 08:34 |
| infinity | It's a bit verbose, to be sure, but why deviate intentionally from the Debian changelog when it describes the actual changes? | 08:35 |
| Q-FUNK | deviate? how? | 08:35 |
| infinity | Q-FUNK: You're not, I'm asking ROAF. | 08:35 |
| infinity | Q-FUNK: Who seems to want the changelog shortened for no clear reason. | 08:35 |
| infinity | RAOF: Whils it's traditional for SRUs to be cherry-picks, when this one is literally a sync of Debian packaging changes, using the Debian changelog entries seems the same thing to do. | 08:36 |
| RAOF | I'd like the changelog to be a log of the changes to *that* package; as it was, it described a bunch of things which were done and then reverted. | 08:36 |
| infinity | Well, there's that. | 08:36 |
| infinity | But, like I said, it's a sync (sort of), so having the history there isn't harming anyone. | 08:37 |
| RAOF | That said, I'm reasonably happy to harmonise my views with the rest of the SRU team here. | 08:38 |
| infinity | Since it needs an Ubuntu entry anyway (obviously), the ~lucidM and ~maverickN entries can point-form "this is what's being fixed". | 08:38 |
| infinity | But having the Debian history before that doesn't hurt. | 08:38 |
| RAOF | I'm not strongly against having the full Debian changelog in there. As it was, though, it wasn't clear what bugs it was trying to fix, and it seemed to have a bunch of unrelated changes for the bug it looked to me like it wanted to fix. | 08:39 |
| infinity | Yeah, I get that. | 08:40 |
| infinity | Like I said, a nice summary in the Ubuntu changelog should resolve that. | 08:40 |
| RAOF | Q-FUNK: So, if you replaced the top changelog entry with a summary of the Ubuntu bugs that it's fixing (and they've got lucid and maverick tasks), that would be fine. | 08:40 |
| RAOF | (As in - the one targetting {lucid,maverick}-proposed. Not the top Debian entry) | 08:41 |
| evfool | ping mvo | 08:41 |
| Q-FUNK | RAOF: the thing is, you added tasks for these on the other bug after my upload. | 08:41 |
| RAOF | Q-FUNK: Is that a problem? That's (one of) the bugs the upload will fix, right? | 08:42 |
| Q-FUNK | RAOF: i can add it now, of course. :) what should version should I call it? ~lucid2 and ~mavercik2 ? | 08:43 |
| RAOF | Q-FUNK: You should be able to version it ~lucid1 and ~maverick1 as I rejected them from the queue. I think :) | 08:44 |
| infinity | You think correctly. | 08:44 |
| Q-FUNK | RAOF: ok, I thought that if once rejected, one cannot upload the same again | 08:44 |
| RAOF | No, once *accepted* you can't upload the same again :) | 08:44 |
| RAOF | The archive would get all narky. | 08:44 |
| mvo | evfool: hello | 08:45 |
| infinity | RAOF: No so much narky, as it would just auto-reject the uploads. | 08:45 |
| evfool | what happened with the lp:python-apt branch? lp says it's not accessible since 20th of May | 08:45 |
| evfool | mvo^ | 08:45 |
| mvo | evfool: oh, let me check | 08:46 |
| Q-FUNK | alright. pushing lucid-proposed now | 08:46 |
| Q-FUNK | and now maverick | 08:47 |
| mvo | evfool: I fiddled around in LP now, lets see if it helps | 08:47 |
| Q-FUNK | hopwfully, the changelog entry is a bit more clear as to what this is | 08:47 |
| dholbach | Riddell, are you going to land your u-p-g branches? :) | 08:48 |
| Riddell | dholbach: yes, that's first on my todo list after e-mail processing | 08:48 |
| dholbach | yoohoo! | 08:48 |
| * dholbach hugs Riddell | 08:48 | |
| evfool | thanks mvo | 08:48 |
| Q-FUNK | oh, hi, dholbach :) | 08:49 |
| dholbach | hi Q-FUNK | 08:49 |
| evfool | mvo for 410310, the bug for the download size inconsistencies between apt strutl.cc and update-manager humanize_size, we might have to reimplement the same method in humanize_size as in strutl.cc SizeToStr, as just calling the apt method won't work because: it has a different format (8000 B is 8000 B, whereas in u-m it should be 8 kB), and it is not translatable | 08:56 |
| evfool | mvo: what do you think? | 08:57 |
| mvo_ | evfool: yeah, that sounds like it was the reason for adding humanize_size. how hard do you consider this to be? will it be enough to move from 1024 to 1000 or is there more to it? | 08:58 |
| evfool | evfool: moving from 1024 to 1000 and finding a way to use the locale-specific decimal separator instead of the comma should do it... although that will still leave some inconsistencies with apt (8000 B in apt = 8 kB in u-m) | 09:00 |
| evfool | mvo^ | 09:00 |
| * Amoz waves to dholbach | 09:42 | |
| dholbach | hey Amoz | 09:42 |
| Amoz | to regenerate the .desktop files cache, one use the command desktop-file-install --rebuild-mime-info-cache right? | 09:44 |
| seb128 | !pilot in | 09:44 |
| seb128 | !pilot on | 09:45 |
| seb128 | bah | 09:45 |
| seb128 | @pilot in | 09:45 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 | ||
| seb128 | \o/ | 09:45 |
| Amoz | no flying for you today seb128 | 09:45 |
| seb128 | don't say that, it would make dholbach sad :p | 09:45 |
| * dholbach hugs seb128 | 09:46 | |
| seb128 | dholbach, ;-) hug! | 09:46 |
| tkamppeter | Seems that there is a problem with the buildds: See https://launchpadlibrarian.net/75925983/buildlog_ubuntu-oneiric-amd64.foomatic-filters_4.0.8-0ubuntu1_FAILEDTOBUILD.txt.gz: First one sees that gcc gets correctly installed into the chroot and then ./configure complains that it cannot find gcc. | 10:19 |
| seb128 | tkamppeter, that's not the error | 10:20 |
| mvo | evfool: \o/ for your u-m branch, I will merge after lunch | 10:20 |
| seb128 | "checking for pkg-config... no | 10:20 |
| seb128 | checking for DBUS... configure: error: The pkg-config script could not be found or is too old. Make sure it" | 10:20 |
| seb128 | tkamppeter, ^ that's your error | 10:20 |
| seb128 | tkamppeter, you need to build-depends on pkg-config | 10:20 |
| evfool | mvo: thanks | 10:21 |
| tkamppeter | seb128, thanks. | 10:23 |
| seb128 | yw | 10:23 |
| CatFish | WHATS UNBUNTU | 10:28 |
| directhex | i wonder what the likelihood of an ipv6 user not knowing what ubuntu is, given no residential DSL provider does v6 yet | 10:33 |
| persia | directhex: Depends on the location: all the residential providers where I live do IPv6. That correction aside, I've no data to answer your primary question. | 10:35 |
| Amoz | apparently he found the IRC channel. | 10:36 |
| jelmer | directhex: my residential DSL provider (one of the larger ones) does IPv6 too | 10:37 |
| CatFish | see me walking treu winhost | 10:37 |
| directhex | apparently it's just the UK where broadband providers think IPv6 is some funny thing not worth doing, then | 10:38 |
| CatFish | see him true my window | 10:38 |
| dholbach | Riddell, thanks a lot for your work on this! | 10:39 |
| CatFish | jan de wandelaar | 10:40 |
| === MacSlow is now known as MacSlow|lunch | ||
| Riddell | dholbach: more to come I think. although it'll need some of the worse UDD bugs fixes before the guide can be made public | 10:47 |
| dholbach | Riddell, I'm looking forward to it | 10:49 |
| geser | directhex: not only UK, in Germany "T-Com" (one of the bigger providers) plans a beta phase with ipv6 (dual-stack) for customers this year | 11:06 |
| nobuto | seb128: Could you review my debdiff for merge request Bug #811892? | 11:20 |
| ubottu | Launchpad bug 811892 in mozc (Ubuntu) "Please merge mozc 1.1.773.102-1 (multiverse) from Debian unstable (non-free)" [Wishlist,Confirmed] https://launchpad.net/bugs/811892 | 11:20 |
| === MacSlow|lunch is now known as MacSlow | ||
| ScottK | directhex: It's not just the UK. | 12:02 |
| === _LibertyZero is now known as LibertyZero | ||
| ahasenack | hi guys, can I get someone from SRU to sponsor this Lucid one? https://bugs.launchpad.net/landscape-client/+bug/813477 | 12:17 |
| ubottu | Ubuntu bug 813477 in landscape-client (Ubuntu Lucid) "Update landscape-client to 11.07.1.1" [Undecided,New] | 12:17 |
| zul | ahasenack: i can do it today | 12:21 |
| ahasenack | zul: thanks. Just lucid, ok? I haven't finished testing the others | 12:22 |
| zul | sure | 12:22 |
| === ara_ is now known as ara | ||
| hallyn | SpamapS: jhunt_: hey, am I right that both runlevel 2 and networking.conf won't happen until mounted-varrun is emitted (by way of local-filesystems)? | 13:21 |
| hallyn | I'm a little puzzled by the last comment in bug 495394. Unless he has non-upstartified customizations, his libvirt should *not* be starting before /var is available... | 13:22 |
| ubottu | Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394 | 13:22 |
| jhunt_ | hallyn: yes, that's right. I wonder what his fstab shows? autofs? Also he mentioned "compiled locally" - did he install it properly I wonder? | 13:37 |
| hallyn | jhunt_: that's what i was wondering, but i didn't want to go hurling around accusations without making sure i was understanding right first :) thanks | 13:39 |
| SpamapS | hallyn: ehhh | 14:04 |
| SpamapS | hallyn: runlevel 2 is a lot more general than that, I wouldn't count on certain events having been emitted before it, so much as it is supposed to mean a certain state has been achieved | 14:05 |
| SpamapS | hallyn: currently the only guarantee you have in runlevel 2 is that lo is up.. tho I should be changing that soon to be "all auto interfaces in /etc/network/interfaces are up" | 14:07 |
| * SpamapS would be done w/ that if not for having to finish OSCON slides | 14:07 | |
| hallyn | SpamapS: hm. ok. | 14:12 |
| === Mirv_ is now known as Mirv | ||
| hallyn | SpamapS: certainly /etc/networking.conf waits on local-filesystems. Does local-filesystems wait on mounted-varrun? | 14:13 |
| hallyn | I would have thought so, but unfortunately that's hidden in the mountall source and not documented under /etc/init/ | 14:13 |
| SpamapS | hallyn: networking.conf is, IMO, poorly named. slangasek described it as a 'last ditch attempt to run ifup -a before runlevel 2' | 14:14 |
| SpamapS | hallyn: the reality is that even w/ a server some network interfaces won't be available until udev has said they're available. | 14:15 |
| SpamapS | hallyn: local-filesystems is a signal that means all non remote filesystems have been mounted. So it should always come after any mounted events that describe local filesystems. | 14:16 |
| SpamapS | hallyn: I'm not aware of a 'mounted-varrun' event though | 14:17 |
| hallyn | yeah i'm not finding it | 14:17 |
| hallyn | SpamapS: libvirt is (now) wiating on 'stopped networking' so your comment about waiting for udev is moot :) | 14:17 |
| === bdmurray_ is now known as bdmurray | ||
| hallyn | so i guess i could add 'stopped mounted-varrun'. but it still seems like runlevel 2 should not be reached until that happens anyway | 14:18 |
| jhunt_ | hallyn, SpamapS: "started They had mobile phones in the 19th Century?! Damn that infernal | 14:19 |
| jhunt_ | DeLorean, changing history! | 14:19 |
| jhunt_ | eeerrr | 14:19 |
| SpamapS | hallyn: the change I'm working on will make runlevel 2 wait on all interfaces marked 'auto' in /etc/network/interfaces .. which means runlevel 2 will be more reliable for servers. | 14:19 |
| jhunt_ | hallyn: SpamapS: "started mounted varrun" | 14:19 |
| SpamapS | what is this mounted-varrun ? | 14:19 |
| jhunt_ | hallyn: SpamapS: take 3: "started mounted-varrun" | 14:19 |
| hallyn | jhunt_: so is local-filesystems not dependent on started mounted-varrun (or stopped mounted-varrune ven)? | 14:20 |
| hallyn | s/\<ven/even | 14:20 |
| jhunt_ | Captain! We all seem to be suffering from some sort of warp in the brain/finger continuum :) | 14:22 |
| SpamapS | This is heavy | 14:22 |
| * hallyn resists the urge to quote Doc | 14:23 | |
| SpamapS | hallyn: please explain to me where you are seeing references to something called mounted-varrun | 14:23 |
| slangasek | local-filesystems is not dependen on started mounted-varrun | 14:23 |
| slangasek | SpamapS: removed in oneiric, since /var/run is removed | 14:23 |
| jhunt_ | SpamapS: the mounted-* jobs are in the mountall pkg. | 14:23 |
| SpamapS | ahh | 14:24 |
| slangasek | the replacing /etc/init/mounted-run.conf job does almost exactly the same thing | 14:24 |
| hallyn | slangasek: ok, i wasn't clear from the man.7 pages whether 'all local fileystems in fstab' includes those in /lib/init/fstab | 14:24 |
| hallyn | slangasek: so does 'filesystems.7' do it? | 14:24 |
| slangasek | hallyn: mounted-varrun is not the job that mounts /var/run! | 14:24 |
| slangasek | it's a job that's run *after* /var/run is mounted | 14:24 |
| hallyn | slangasek: no, but it lets me know it has happened | 14:24 |
| hallyn | yes | 14:24 |
| slangasek | hallyn: what is the problem you're trying to solve? | 14:25 |
| hallyn | making sure that libvirt-bin has /var available when it starts. bug 495394 | 14:25 |
| ubottu | Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394 | 14:25 |
| slangasek | ah, let's see | 14:25 |
| SpamapS | hallyn: why would libvirt-bin need to start before runlevel 2? | 14:25 |
| hallyn | SpamapS: it shouldn't | 14:26 |
| hallyn | SpamapS: what i'm saying is runlevel 2 may not be sufficient | 14:26 |
| hallyn | i was trying to trace a dependency from /var being mounted to runlevel 2 | 14:26 |
| hallyn | Franck78 is implying that is not there | 14:26 |
| SpamapS | hallyn: reading now | 14:26 |
| slangasek | no, virtual-filesystems will be emitted before filesystem | 14:27 |
| hallyn | sorry, it's a bit long | 14:27 |
| slangasek | (note that /etc/init/rc-sysinit.conf depends on *filesystem*, not local-filesystems) | 14:27 |
| SpamapS | no I have been keeping up in my email client actually | 14:27 |
| slangasek | so this sounds like foot-shooting rather than an Ubuntu bug | 14:27 |
| hallyn | slangasek: and does virtual-filesystems imply both /lib/init/fstab and /etc/fstab? | 14:27 |
| slangasek | yes | 14:27 |
| hallyn | the manpage is not crystal-clear on that | 14:28 |
| hallyn | ok | 14:28 |
| hallyn | yeah, i wonder if he has a persistent /var over-mounting the fstab one | 14:28 |
| hallyn | slangasek: ok, i'll just wait on him to file a new bug with more info | 14:28 |
| hallyn | slangasek: SpamapS: jhunt_: thanks | 14:28 |
| slangasek | mountall knows what to do with /etc/fstab entries that shadow /lib/init/fstab ones | 14:28 |
| SpamapS | Honestly 99.9 % of things should start in runlevel 2. The confusion has come from the fact that sometimes the network interfaces that a service depends on won't be there, so there are way too many jobs that do 'net-device-up IFACE!=lo' | 14:29 |
| * SpamapS hopes to be un-distracted enough this week to finish fixing that | 14:29 | |
| slangasek | fixing what? | 14:29 |
| hallyn | :) | 14:29 |
| hallyn | SpamapS: when you do, maybe you can remove the extra start on from libvirt-bin in oneiric again :) | 14:30 |
| SpamapS | for servers that have their network interfaces configured in /etc/network/interfaces, have runlevel 2 wait until all the auto interfaces are up | 14:30 |
| SpamapS | slangasek: ^ | 14:30 |
| slangasek | SpamapS: causing your ssh server to fail to start in the event of a network card issue? | 14:30 |
| slangasek | ah, no, ssh will 'start on filesystem' curiously | 14:31 |
| SpamapS | slangasek: we sat and talked about this in Budapest.. you may not have grasped the plan. | 14:31 |
| slangasek | SpamapS: I was only in for part of the discussion :) | 14:31 |
| hallyn | maybe it'd be safer to just add the extra 'auto-network-up' event *without* changing runlevel 2 | 14:31 |
| SpamapS | The issue is there are many services which fail miserably in runlevel 2 because their network is not available. | 14:32 |
| slangasek | ok, I don't see anything else that's a problem if it waits for all the auto-interfaces to start, and ssh is covered, so | 14:32 |
| slangasek | ignore my windmilling arms | 14:32 |
| SpamapS | slangasek: and ssh starts on filesystem or runlevel [2345] .. so its covered anyway | 14:32 |
| slangasek | yes | 14:32 |
| slangasek | though that's a curious start rule | 14:32 |
| SpamapS | its to cover the move to single user and then back to 2 | 14:33 |
| SpamapS | which *many* jobs do not do right | 14:33 |
| slangasek | ah | 14:33 |
| SpamapS | Many stop but never start back up | 14:33 |
| SpamapS | little things.. like.. upstart-socket-bridge | 14:35 |
| SpamapS | :-/ | 14:35 |
| jhunt_ | ... and also many jobs start and never stop :| | 14:36 |
| SpamapS | jhunt_: those at least have reduced in number as the bug reports are more comon for them. :) | 14:37 |
| jhunt_ | SpamapS: sure, but those jobs with no "stop on" are causing me interesting problems for a pure upstart shutdown. I'm certainly in favour of a more predictable shutdown sequence. | 14:38 |
| SpamapS | jhunt_: some things don't actually need to ever stop | 14:38 |
| ion | With first-class states, shutdown would be trivial. Have a “system” state which goes down on shutdown, and have that level change trigger anything you need to happen on shutdown. | 14:39 |
| ion | s/on shutdown/on requested shutdown/ | 14:39 |
| SpamapS | ion: we call those "jobs" .. we have that.. we're just not using it. :-/ | 14:39 |
| SpamapS | I've proposed this for a while.. have things follow a few virtual services rather than almost everything concocting their own magic recipe for start and stop. | 14:40 |
| SpamapS | My focus has turned elsewhere of late.. but I hope to spend some time working on doing that on a small scale before FF | 14:41 |
| === dendrobates is now known as dendro-afk | ||
| superm1 | slangasek, according to https://wiki.ubuntu.com/ArchiveAdministration today is you right? would you mind helping look at the problem that kirkland encountered on bug 811231? | 15:12 |
| ubottu | Launchpad bug 811231 in dkms (Ubuntu) "Sync dkms 2.2.0.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/811231 | 15:12 |
| hrw | slangasek: how to disable armhf in eglibc during armel build? | 15:21 |
| hrw | slangasek: found | 15:43 |
| apw | cjwatson, it seems tha that the linux-lts-backport-maverick binary packages have ended up in universe, -natty seems to be ok | 16:04 |
| cjwatson | apw: in what suites? | 16:08 |
| cjwatson | ... never mind, I'll work it out | 16:08 |
| cjwatson | apw: (note that I'm at DebConf - I'm dealing with this one now, but for the next couple of weeks it's probably better to find a different archive admin) | 16:08 |
| cjwatson | apw: should be fixed after the next publisher run, so ~1h30m | 16:10 |
| smoser | cjwatson, is i known bug that mini-iso kernel crashes on boot ? | 16:12 |
| smoser | oneiric from http://archive.ubuntu.com/ubuntu/dists/oneiric/main/installer-amd64/current/images/netboot/mini.iso under kvm | 16:12 |
| smoser | (this is new in hte last 2 weeks) | 16:13 |
| cjwatson | smoser: bug 815962 | 16:13 |
| ubottu | Launchpad bug 815962 in udev (Ubuntu) "oneiric d-i based images kernel panic on boot" [Critical,Fix released] https://launchpad.net/bugs/815962 | 16:13 |
| smoser | thanks | 16:13 |
| cjwatson | it'll be fixed visibly for real after the next d-i upload | 16:13 |
| === calc is now known as Guest47738 | ||
| === deryck is now known as deryck[lunch] | ||
| apw | cjwatson, ahh didn't realise, will find others to hastle, and thanks | 16:40 |
| apw | jhunt_, hey we are seeing machines wherein halt has stopped working (as in sudo halt) but all other kinds of shutdown including halt -p do the right thing; the wrong thing being saying "halting" and leaving the power on | 17:09 |
| apw | jhunt_, i see upstart has changed recently and wonder if there could be any correlation | 17:10 |
| tumbleweed | bdrung: is the lintian build failure you reported not just a symptom of our recent umask change? | 17:12 |
| smoser | anyone else have issues using squid-deb-proxy and ppas? | 17:18 |
| infinity | apw: halt without switches should do exactly as you describe (print "halting" and leave the power on) | 17:18 |
| infinity | apw: The fact that someone at some point made ours behave like "halt -p" was a bug. :P | 17:19 |
| === dendro-afk is now known as dendrobates | ||
| smoser | i dont expect it to proxy the ppas, but i think that i'm getting issues having it in the way, as it ends up giving me things like: | 17:19 |
| smoser | W: Failed to fetch http://ppa.launchpad.net/dotdee/ppa/ubuntu/dists/natty/main/source/Sources 403 Forbidden | 17:19 |
| smoser | mvo_, ^ ? | 17:19 |
| apw | infinity, really, what use is that ? | 17:20 |
| apw | smb, ^^ | 17:20 |
| kirkland | smoser: i think you have to whitelist it in the config file | 17:20 |
| smb | apw, saw it | 17:20 |
| * smb wonders about the use of that as well | 17:20 | |
| kirkland | smoser: i think i talked to mvo about that in dublin, changing the default config file to whitelist ppas | 17:20 |
| smoser | doesn't htat seem like a serious bug ? | 17:21 |
| smoser | you're telling me that you cannot use squid-deb-proxy and ppas together? | 17:21 |
| smoser | (that is what i'm seeing, but i didn't think it could be so serious) | 17:21 |
| infinity | apw: It's just the way it's always been in UNIX systems until we broke it. But it does also serve some purpose, in that seeing the last output of halt can be useful, and much less so if you cut the power. | 17:21 |
| infinity | apw: Either way. I'm not the one who fixed it, I'm just pointing out that it's now fixed, not broken. :P | 17:22 |
| apw | infinity, ok ... i guess i'll crawl back under my rock :) | 17:22 |
| smoser | kirkland, ^ | 17:26 |
| Daviey | smoser: on oneiric? | 17:28 |
| Daviey | smoser: I thought that mvo_ added that to be enabled by default? Maybe we need to preseed it enabled.. can't remember the detail. | 17:29 |
| smoser | Daviey, yes. on oneiric. | 17:30 |
| smoser | i'm seeing this just ow, where i have: | 17:30 |
| smoser | * host system running squid-deb-proxy | 17:30 |
| smoser | * libvirt install of guest system passing it 'd-i mirror/http/proxy string http://192.168.1.102:8000/' | 17:31 |
| smoser | hm... so i guess it might be me that is doing something funny though... | 17:31 |
| smoser | wonder if that can be made to work. generally its really nice for guest network installs except if they have to hit a ppa, it breaks. | 17:31 |
| Daviey | smoser: no, it sounds like squid-deb-proxy is correctly blocking if that is the rule. | 17:31 |
| Daviey | But you should be able to autofind the squid server. | 17:32 |
| smoser | i'm confused. | 17:32 |
| smoser | why would you want it to block | 17:32 |
| smoser | ie, i'm getting permission denied. why would that be desireable. | 17:33 |
| bdrung | tumbleweed: maybe. what was changed in umask? | 17:33 |
| Daviey | smoser: You think it should proxy * ? | 17:34 |
| SpamapS | smoser: I've removed squid-deb-proxy* from my systems because of this problem | 17:34 |
| SpamapS | bug 804267 if you're so inclined to comment | 17:35 |
| ubottu | Launchpad bug 804267 in squid-deb-proxy (Ubuntu) "squid-deb-proxy does not allow downloading from arbitrary mirrors of packages" [Undecided,Confirmed] https://launchpad.net/bugs/804267 | 17:35 |
| tumbleweed | bdrung: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-June/000862.html | 17:35 |
| Keybuk | jhunt_: about? | 17:36 |
| smoser | Daviey, why would you not want it to ? | 17:37 |
| Daviey | smoser: *shrug*, i suppose mvo_ wanted to restrict it to default install of official repo's | 17:39 |
| SpamapS | It should proxy everything apt would reasonably request. | 17:39 |
| SpamapS | OR the client should find a way to only make apt proxy official repos. | 17:39 |
| smoser | right. as it is, it basically breaks you if you have ppas | 17:42 |
| === dendrobates is now known as dendro-afk | ||
| === deryck[lunch] is now known as deryck | ||
| adam_g | uhm. is there any reason why grab-merge or 'bzr merge' would completely ignore a file in a debian packages debian/patches/ directory? | 17:48 |
| SpamapS | smoser: hence it going away from all of my systems (as of our hacking session in Dublin actually ;) | 17:50 |
| SpamapS | adam_g: bzr merge must think that it was legitimately deleted | 17:51 |
| adam_g | SpamapS: the debian repository hasn't been touched, its fresh from 'bzr branch' | 17:53 |
| bdrung | tumbleweed: i can't reproduce the bug by setting umask to 0002 | 17:57 |
| bdrung | tumbleweed: do you have some minutes time for me to help debug lintian? | 17:59 |
| tumbleweed | bdrung: I must go and have supper, I'm afraid, but I'll see if I can look later (if the cheese and wine party doesn't kill me) :) | 17:59 |
| bdrung | tumbleweed: you are at debconf? | 17:59 |
| bdrung | tumbleweed: i had an exam today | 18:00 |
| mvo_ | smoser: hello, sorry for the delay, I was at dinner. so the idea behind it is that you can enable squid-deb-proxy and by default its "safe" in the sense that it allows only trusted sources. its easy to enable everything. I guess its a debatable default, most home users will want it open, most coperation (I assume) will want it the other way around | 18:21 |
| slangasek | superm1: limited availability, I'm at DebConf at the moment | 18:23 |
| slangasek | ah, that's an easy one though | 18:23 |
| slangasek | kirkland, superm1: sync blacklisting with a rationale of "orig.tar.gz mismatch" can be dropped as soon as the upstream version revs | 18:24 |
| superm1 | ah ok | 18:24 |
| === Ursinha is now known as Ursinha-lunch | ||
| jdstrand | SpamapS: hey, I see that bug #495394 is now verification-done for all three releases, and sitting at 13 days in -proposed (according to LP). mind if I push it? | 19:14 |
| ubottu | Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394 | 19:14 |
| jdstrand | SpamapS: (to -updates) | 19:14 |
| Laney | mdke: you need to add a postinst that calls update-alternatives --remove-all $foo if $1 = configure and dpkg --compare-versions $2 le-nl the-last-version-to-provide-alternatives | 19:22 |
| Laney | with some quoting | 19:24 |
| hallyn | jdstrand: \o/ | 19:24 |
| jdstrand | SpamapS: am am just going to do it. it is in green on http://people.canonical.com/~ubuntu-archive/pending-sru.html for all releases | 19:28 |
| SpamapS | jdstrand: days is not at >= 7 though | 19:33 |
| jdstrand | SpamapS: it says 13 | 19:33 |
| jdstrand | in both LP and http://people.canonical.com/~ubuntu-archive/pending-sru.html | 19:33 |
| SpamapS | Oh crap somebody said qemu-kvm | 19:33 |
| SpamapS | not libvirt | 19:33 |
| SpamapS | Yeah libvirt is ready to go now | 19:34 |
| jdstrand | SpamapS: consider it done | 19:34 |
| jdstrand | SpamapS: (literally) | 19:34 |
| jdstrand | :) | 19:34 |
| SpamapS | jdstrand: cool | 19:34 |
| broder | the /run migration is finished, right? is there any reason then that https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/initramfs-tools/oneiric-201106221912/+merge/65551 can't be bumped from the queue? | 19:49 |
| seb128 | @pilot out | 19:57 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| seb128 | @pilot in | 19:57 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 | ||
| seb128 | @pilot out | 19:57 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === tlp_ is now known as tlp | ||
| Laney | @shake it all about | 20:29 |
| udevbot | Error: "shake" is not a valid command. | 20:29 |
| * micahg thinks udevbot should learn the hokey pokey | 20:33 | |
| === yofel_ is now known as yofel | ||
| broder | Laney: +1 | 21:25 |
| Laney | broder: hmm? | 21:32 |
| Laney | also, can backporters ack their own requests or is that Naughty™? | 21:32 |
| infinity | Laney: Very naughty. | 21:32 |
| infinity | Laney: I'm writing archive-spank.py as we speak to deal with this issue. | 21:33 |
| * Laney sits on the naughty step | 21:33 | |
| ScottK | infinity: You assume he wouldn't like that. | 21:33 |
| infinity | ScottK: I'm making no such assumptions. | 21:34 |
| ScottK | Laney: No, it's fine as long as it really builds/installs/runs. | 21:34 |
| infinity | ScottK: You assume I wouldn't appreciate it if he did. | 21:34 |
| ScottK | Good point. Sorry. | 21:34 |
| Laney | Let's just try it and see. | 21:35 |
| * Laney requests one. Get the spaking ready. | 21:35 | |
| infinity | If this launches into a Holy Grail recital, with the next inevitable line, we might have to stop talking about this in a public channel. :P | 21:36 |
| ScottK | infinity: Laney misspelled a word, so the cycle is broken. I think it's safe. | 21:37 |
| Keybuk | a spaking! a spaking! | 21:37 |
| Laney | spak me well | 21:37 |
| ScottK | Nevermind. We're doomed now. | 21:37 |
| infinity | Keybuk: And after the spakings, the aural sax? | 21:37 |
| * nigelb looks at channel, and the conversation, and blinks. | 21:38 | |
| nigelb | Am I hallucinating? O.O | 21:38 |
| infinity | Yes. | 21:38 |
| nigelb | hm, 3 am. Yeah. Probably need sleep. | 21:38 |
| Keybuk | infinity: I'm trying to think of an archive-related pun instead | 21:39 |
| Keybuk | so far all I've got is "the soyuz sex" | 21:39 |
| Keybuk | I'll work on it | 21:39 |
| infinity | Keybuk: That sounds like the worst night EVER. | 21:39 |
| * nigelb refrains from violating CoC with puns | 21:39 | |
| Laney | have you /seen/ the size of those things? | 21:39 |
| === Ursinha-lunch is now known as Ursinha | ||
| * micahg keeps forgetting he wants to be a backporter | 21:51 | |
| Laney | you're remembering now: go triage bugs :-) | 21:52 |
| * micahg still has work todo, maybe later | 21:52 | |
| Laney | hah | 21:52 |
| nigelb | Laney: ah, there was something I need to talk to you about. | 21:53 |
| Laney | uh oh! | 21:53 |
| nigelb | Basically, with the new packaging guide, I was hoping for some comments about a change | 21:53 |
| nigelb | How about having a numbered step of things a new person would have to do. Like a quickstart. It was discussed before, and I'd like to actually get it done | 21:54 |
| nigelb | Over the weekend, I checked out new contributor documentation with another project (mozilla) and compared it back with ours | 21:54 |
| nigelb | Number of things we can learn off them. | 21:54 |
| Laney | "to do" to achieve what? | 21:55 |
| nigelb | To fix a bug in Ubuntu. | 21:55 |
| Laney | different to http://people.canonical.com/~dholbach/packaging-guide/html/fixing-a-bug.html ? | 21:56 |
| Laney | apart from the fact that that page is misleading | 21:56 |
| nigelb | misleading because of UDD-only approach | 21:57 |
| nigelb | ? | 21:57 |
| nigelb | So, what I'm comparing against is this page - https://developer.mozilla.org/En/Introduction | 21:58 |
| nigelb | Its numbered, so there are defined steps to do. | 21:58 |
| nigelb | I <3 Step 3 | 21:58 |
| nigelb | Something we're lacking, I'm trying to see how we can use harvest to fill that gap. | 21:58 |
| Laney | yeah, you could make those headings numbered if you like | 21:59 |
| nigelb | Also, note that there are "bugs identified as being good for newcomers" | 21:59 |
| nigelb | They are actually *real* easy bugs to get a flow for the process. | 21:59 |
| Laney | a la bitesize? | 21:59 |
| nigelb | even smaller :) | 21:59 |
| nigelb | Mostly "remove one line of code", "typo" | 22:00 |
| nigelb | bitesize bugs I've noticed are ones that go into upstream better than into Ubuntu | 22:00 |
| Laney | Stuff you don't want to fix in a downstream patch. | 22:00 |
| nigelb | exactly. | 22:00 |
| nigelb | bah, I'm not awake enough for a proper conversation | 22:00 |
| nigelb | Before I give up, I really liked the mentored bugs concept | 22:01 |
| nigelb | I checked out a few of them | 22:01 |
| nigelb | the comments had most of what needed to be done and who to contact in doubt | 22:01 |
| Laney | I helped a couple of people through those, it was probably useful. | 22:01 |
| nigelb | Now I give up, really tired. Sigh 3:30 am. | 22:02 |
| Laney | what I was alluding to is that page fails to mention upstreaming at all. | 22:03 |
| Laney | which probably violates "there is no surprises" (itself already a shaky claim) | 22:03 |
| nigelb | Yes, that and it doesn't mention the old workflow | 22:03 |
| nigelb | the package you pick to work on may not be in bzr. | 22:04 |
| Laney | I can't see the guide being released as it is until UDD is free of kinks | 22:04 |
| Laney | ScottK: micahg: Please snip some more in your -devel@ discussion :-) | 22:05 |
| nigelb | hm, which is probably a good thing. | 22:05 |
| nigelb | I thing something on micahg's client is messing up the email :) | 22:05 |
| nigelb | *think | 22:05 |
| nigelb | <-- bed | 22:06 |
| Laney | night | 22:06 |
| Laney | (I'll look at any MPs you have) | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!