| slangasek | soren: so if this is at boot time, the /intent/ is that the bridging interface will be brought up once any of the child interfaces are brought up; but the Debian maintainer of ifenslave-2.6 brought up a concern that there might not be any locking here, so if both child interfaces start in parallel, one could miss. Does that sound like what you're seeing? | 00:04 |
|---|---|---|
| === dendrobates is now known as dendro-afk | ||
| rickspencer3 | kklimonda, https://bugs.edge.launchpad.net/ubuntu/+source/glib2.0/+bug/638513 | 00:15 |
| ubottu | Launchpad bug 638513 in glib2.0 (Ubuntu) "PyGtk App Core dumps" [Undecided,New] | 00:15 |
| === evilnhandler is now known as nhandler | ||
| === nhandler_ is now known as nhandler | ||
| kklimonda | rickspencer3: I've got a smaller testcase: http://pastebin.com/RwY03ht8 | 00:47 |
| rickspencer3 | huh, I thought I tried something like that, and it didn't repro | 00:48 |
| kklimonda | lets see if I can reproduce it in C | 00:48 |
| rickspencer3 | anyway, thanks for that | 00:48 |
| rickspencer3 | much better | 00:48 |
| kklimonda | I can't reproduce it with a hasty written C program but it's way too late for me to debug it further.. but I think that pygtk may be to blame after all | 00:57 |
| rickspencer3 | kklimonda, makes sense | 00:59 |
| rickspencer3 | thanks for looking into it | 00:59 |
| === bjf is now known as bjf[afk] | ||
| andreserl | slangasek, ping | 02:07 |
| slangasek | andreserl: hey there | 02:07 |
| andreserl | slangasek, hi. I just got your email. 1st. There was no FFe filed given that I understood these as a bug fix to get pacemaker in better shape, so I saw no need to file an FFe | 02:09 |
| andreserl | second, the overriden warnings also appeared when the libraries were back in pacemaker itself | 02:10 |
| slangasek | andreserl: fair enough; I happen to disagree that it doesn't need an FFe, but I see that it can be a matter of opinion whether this is a new feature vs. a bugfix | 02:10 |
| andreserl | slangasek, third, what's your recommendation or approach to fix this :) | 02:10 |
| slangasek | andreserl: the overridden warnings aren't new, yes - they're also not the reason for the reject | 02:10 |
| slangasek | andreserl: my recommendation depends on how this package is intended to be used. Are you splitting these packages because another new package will be uploaded that uses libpacemaker-dev? | 02:11 |
| andreserl | slangasek, not really. We, (me and ivoks) are trying to get pacemaker and cluster-glue into main. cluster-glue was rejected because of similar issue as pacemaker | 02:13 |
| andreserl | so as discussed with ivoks, he came to a conclusion that the split was the best to make them *more policy* compliant | 02:13 |
| slangasek | andreserl: heh - I would have rejected libcluster-glue as well if I had seen that :) | 02:14 |
| andreserl | we've been trying to get this done in upstream (library split) however, they are not interested on it :) | 02:14 |
| slangasek | what part needs done upstream? | 02:14 |
| andreserl | slangasek, pacemaker, cluster-glue, and heartbeat have a similar separation of libraries | 02:14 |
| andreserl | slangasek, upstream is working with debian on getting the packages, and as per ivoks discussion, they have rejected the need to have the library split in pacemaker and cluster-glue | 02:15 |
| slangasek | I'm not sure what you mean, the libraries are already split | 02:15 |
| andreserl | slangasek, I'm sure you;ll understand this better :) https://bugs.launchpad.net/ubuntu/+source/cluster-glue/+bug/527142/comments/13 | 02:16 |
| ubottu | Launchpad bug 527142 in cluster-glue (Ubuntu) "[MIR] cluster-glue" [Undecided,Incomplete] | 02:16 |
| slangasek | ok; so it's more about a delta from the Debian packages | 02:17 |
| slangasek | upstream library split isn't terribly interesting to me one way or the other | 02:17 |
| slangasek | there are plenty of source packages in the archive that build both libraries and executables, and that's fine - the key point is in how you /package/ the libraries so that things don't break on upgrade | 02:18 |
| slangasek | oh; and there are multi-level library interdependencies, and the libraries don't use symbol versioning | 02:19 |
| slangasek | so partial upgrades --> segfaults, yay | 02:20 |
| lifeless | if only it was partial upgrades --> partial segfaults | 02:20 |
| andreserl | if you mean upgrading from ubuntu2 to ubuntu3 (which includes library split), it upgrades as expected according to my tests. Now, if this is the case, the same behaviour should be seen in other packages such as cluster-glue | 02:21 |
| andreserl | given that besides pacemaker, cluster-glue and all other related packages come from upstream | 02:21 |
| slangasek | andreserl: I mean that if one library changes soname and the other doesn't, and the library that doesn't gets upgraded, but an application that linked against both libs is not upgraded, you get segfaults | 02:23 |
| andreserl | i see | 02:24 |
| slangasek | andreserl: so are the libraries in libpacemaker guaranteed not to have any soname changes? | 02:24 |
| slangasek | if that's the case, then this can be accepted | 02:24 |
| slangasek | but first the file conflict between pacemaker and libpacemaker-dev should be resolved | 02:24 |
| slangasek | (so it needs a new upload, no matter what) | 02:25 |
| slangasek | lifeless: which part would you like to segfault? :-) | 02:25 |
| andreserl | slangasek, afaik they wont have soname changes but I'm not sure. I'd rather talk to upstream and get back to you on that | 02:25 |
| slangasek | ok | 02:25 |
| slangasek | that's the main thing I'm concerned about here - forward-planning | 02:26 |
| slangasek | it's a lot harder to retrofit a solution when it comes to lib upgrades | 02:26 |
| andreserl | I see (notice that I'm not a library packager expert, in fact, this is my first attempt to package libraries) | 02:27 |
| andreserl | anyways, on the side of the file conflict between pacemaker and libpacemaker-dev, what's the best approach to address this?? | 02:28 |
| slangasek | andreserl: well, the file that's conflicting doesn't belong in a -dev package because it's a runtime lib | 02:29 |
| slangasek | so I guess putting it in pacemaker only would solve it :) | 02:29 |
| andreserl | slangasek, oh I think I just realized what the issue is. So, yeah it's and easy fix | 02:31 |
| andreserl | ok so, the only thing right now would be to guarantee that there won't be a soname change in future releases, correct? | 02:31 |
| slangasek | andreserl: yes | 02:33 |
| andreserl | slangasek, ok then. I'll discuss this with upstream and get back to you tomorrow. If this is the case, I'll have new packages ready for tomorrow :) | 02:34 |
| andreserl | if not, you'll help me get the packaging in better shape :) | 02:34 |
| slangasek | andreserl: sounds good :)( | 02:37 |
| slangasek | :) | 02:37 |
| * psusi wonders what the deal is with canonicalizing device names from /dev/mapper/foo to /dev/dm-x | 03:01 | |
| andreserl | slangasek, should I address any other lintian stuff such as: E: pacemaker: postinst-must-call-ldconfig usr/lib/service_crm.so | 03:17 |
| === dendro-afk is now known as dendrobates | ||
| slangasek | andreserl: that one seems to be a false positive, given that this is the same file that returns the improper-soname error :) | 04:05 |
| andreserl | slangasek, ok then :) First error is fixed, now just waiting for upstream's word on the sonames :) | 04:29 |
| mwhudson | ScottK: re python-defaults 2.6.6-2 | 05:34 |
| mwhudson | Sep 13 12:02:46 <ScottK> mwhudson: It it's not done by Wednesday, please remind me. | 05:34 |
| mwhudson | i don't think it's been done? | 05:34 |
| === bjf[afk] is now known as bjf | ||
| === almaisan-away is now known as al-maisan | ||
| === bjf is now known as bjf[afk] | ||
| ScottK | mwhudson: No. It hasn't. Unfortunately I'm heading to bed and it turns out I'll be offline almost all of tomorrow. You might also ask doko. | 06:17 |
| mwhudson | ScottK: ok, i'll poke him if i get the chance | 06:17 |
| SpamapS | Hrm.. installing on a Dell mini 1012 w/ netbook edition 10.10 beta.. it seems the installer window is only using half the width of the screen | 06:50 |
| pitti | Good morning | 07:39 |
| SpamapS | wow... installing from 10.10-beta on a netbook has been, so far, extremely painful | 07:43 |
| SpamapS | mutter and plymouth segfaulting.. hundreds of packages to update.. :-P | 07:43 |
| slangasek | SpamapS: plymouth segfaulting, or being killed by the OOM killer? | 07:56 |
| === Zic_ is now known as Zic | ||
| SpamapS | slangasek: Actually I think it was OOM killed | 08:40 |
| SpamapS | slangasek: either way, install on netbook was horrendous | 08:41 |
| SpamapS | and after upgrade, I can't login with a netbook session | 08:41 |
| SpamapS | I just get a blank white screen :-/ | 08:44 |
| soren | slangasek: Nope, this dude only has one interface on the bridge. | 08:56 |
| SpamapS | whoa, and gnome help is all unicode sequences instead of characters | 08:57 |
| soren | slangasek: So if someone has "auto br0" in his /e/n/i, the networking upstart job will attempt to configure it, and adding the interface will fail. Right? | 08:58 |
| soren | slangasek: Err... assuming the physical interface hasn't turned up yet, I mean. | 08:58 |
| === spike_ is now known as spikeWRK | ||
| primes2h | Hello pitti! Is there a way to workaround this in apport-collect? It's a blocker bug. bug #628755 | 09:55 |
| ubottu | Launchpad bug 628755 in w3m (Ubuntu) "Impossible to log in in Launchpad using apport from a tty console" [High,Confirmed] https://launchpad.net/bugs/628755 | 09:55 |
| primes2h | btw, I'm thinking about marking it as "Critical". mmhh.. | 09:57 |
| pitti | primes2h: install links? | 10:28 |
| pitti | primes2h: apport-collect also prints out the URL, so if you have this problem on a remote server, you can just open the URL locally | 10:28 |
| primes2h | pitti: that is ubuntu-bug, apport-collect don't do it. | 10:28 |
| primes2h | at least, I haven't seen links. | 10:29 |
| primes2h | s/don't/doesn't | 10:29 |
| pitti | primes2h: works here | 10:39 |
| pitti | $ apport-collect 12345 | 10:40 |
| pitti | The authorization page: | 10:40 |
| pitti | (https://edge.launchpad.net/+authorize-token?oauth_token=DEADBEEF | 10:40 |
| pitti | should be opening in your browser. [...] | 10:40 |
| primes2h | pitti: Does it appear in a terminal? | 10:40 |
| pitti | yes, that was from a temporary test user I su'ed to | 10:40 |
| pitti | that's standard launchpadlib login_with() | 10:41 |
| primes2h | pitti: I get the "The authorization page: bla bla" only when I quit w3m. I must run apport-collect on tty1 because GUI doesn't start. Does that link allow to upload info from the broken pc even if I put it on another pc browser? | 10:46 |
| pitti | yes | 10:46 |
| primes2h | pitti: I remember that using ubuntu-bug there is an explicit advise about using the link on another pc, in apport-collect there isn't. It would be nice to add it as well. | 10:50 |
| pitti | that'd need to go into launchpadlib | 10:50 |
| pitti | but yes, would be nice | 10:50 |
| primes2h | pitti: btw, I'm going to try it. | 10:51 |
| primes2h | pitti: I can open a bug about that improvement | 10:52 |
| pitti | thanks | 10:52 |
| davmor2 | Hi guys I'm having issues with une this morning I upgraded and I get the new background and gdm, then once I log in I get a white background with a white arrow and that's all, no unity/icons/toolbar etc | 11:03 |
| gord | davmor2, yup, known issue. no fix yet. sorry :( | 11:08 |
| davmor2 | gord: thanks :) | 11:08 |
| davmor2 | gord: is there a bug report for it do you know? | 11:10 |
| gord | davmor2, i'm not aware of one | 11:16 |
| davmor2 | gord thanks :) | 11:17 |
| bilalakhtar | Is bug #604135 worth SRUing into Lucid? | 11:24 |
| ubottu | Launchpad bug 604135 in mplayer (Ubuntu Lucid) "missing "Unsupported PixelFormat 10" fix patch" [Medium,Triaged] https://launchpad.net/bugs/604135 | 11:24 |
| === smb is now known as smb-afk | ||
| pitti | tkamppeter: ok, got the speed up fixed and committed nwo | 11:27 |
| pitti | tkamppeter: for the epson drivers, the current debdiff still doesn't do anything to actually install the key, etc. | 11:27 |
| pitti | so we don't have any authentication at all | 11:27 |
| pitti | and installing that key isn't trivial either | 11:28 |
| bilalakhtar | pitti: Do you think bug #604135 should be SRUed? It is affecting everyone, though it occurs only with a certian type of file, and the fix is a single-line fix. | 11:32 |
| ubottu | Launchpad bug 604135 in mplayer (Ubuntu Lucid) "missing "Unsupported PixelFormat 10" fix patch" [Medium,Triaged] https://launchpad.net/bugs/604135 | 11:32 |
| pitti | hey bilalakhtar, congratulations for joining the MOTU ranks! | 11:32 |
| ogra | pitti, i have an apport question ... | 11:32 |
| * bilalakhtar wonders how pitti came to know about his MOTU application | 11:33 | |
| bilalakhtar | Thanks pitti ! | 11:33 |
| ogra | pitti, is it possible to somehow tell apport in the hooks to assign bugs to a different LP project (other than ubuntu) ? | 11:33 |
| pitti | bilalakhtar: SRU> seems fine, and the lucid task is already approved | 11:33 |
| pitti | bilalakhtar: I saw you getting added to ~motu :) | 11:33 |
| ogra | we'd need something like that for TI images | 11:33 |
| pitti | ogra: yes, it is | 11:33 |
| ogra | how ? i dont find it on the wikipage | 11:33 |
| pitti | ogra: ubuntuone-client already does exactly that to also support PPA builds | 11:33 |
| ogra | ah | 11:34 |
| pitti | ogra: some pointers: | 11:34 |
| ogra | yeah, its for a ppa | 11:34 |
| pitti | /usr/share/doc/apport/crashdb-conf.txt | 11:34 |
| pitti | /usr/share/doc/apport/package-hooks.txt.gz ("Customize the crash DB to use") | 11:34 |
| pitti | ubuntuone example: | 11:34 |
| pitti | - LP configuration: /etc/apport/crashdb.conf.d/ubuntuone-client-crashdb.conf | 11:34 |
| ogra | tsk, who would think to look in the shipped docs :P | 11:35 |
| pitti | /usr/share/apport/package-hooks/source_ubuntuone-client.py | 11:35 |
| pitti | ogra: yeah, it was an utter waste to write them :) | 11:35 |
| * ogra hugs pitti, thanks a lot :) | 11:35 | |
| pitti | ogra: that hook does pretty much what you need, I think | 11:35 |
| pitti | if not apport.packaging.is_distro_package(report['Package'].split()[0]): | 11:35 |
| ogra | perfect, yeah, looks like | 11:35 |
| pitti | report['CrashDB'] = 'ubuntuone' | 11:35 |
| pitti | ogra: that means: "if the package is an Ubuntu native one, report it against Ubuntu, otherwise against the "ubuntuone" crash database | 11:36 |
| pitti | ogra: (i. e. a PPA version or local build) | 11:36 |
| ogra | yeah | 11:36 |
| pitti | ogra: the ubuntuone db is defined in untuone-client-crashdb.conf | 11:36 |
| tkamppeter | pitti, so you have dropped the Epson thingy? | 11:46 |
| pitti | tkamppeter: s/dropped/not committed/ | 11:46 |
| pitti | tkamppeter: just followed up on the bug | 11:46 |
| pitti | I don't see an Epson specific hack which is significantly easier than just implementing the whole thing properly | 11:46 |
| pitti | and I don't think it's correct/okay to statically ship the Epson key in the Ubuntu keyring | 11:47 |
| pitti | we need to fetch the Epson key on demand and verify a trusted path to it | 11:47 |
| pitti | since it could change at any time | 11:47 |
| pitti | (which in this case means to fetch its fingerprint from the openprinting page and compare it) | 11:48 |
| tkamppeter | pitti, so I have to tell Epson that we have no infrastructure to auto-download Epson driver, so best is a formal feature addition via UDS session? | 11:48 |
| tkamppeter | pitti, I have hoped we get it in. For that I reported the bug already much earlier in the development period. | 11:49 |
| pitti | right, but as I said, I'm not on platform this cycle, so I didn't have time for it | 11:50 |
| pitti | and nobody else did it | 11:50 |
| tkamppeter | pitti, did you not say after your first review on Monday that we restrict to Epson (what I did)? I also will advise Epson not to change the key for the time until Natty comes out (and we ship the real solution) and then we ship Epson's key with Maverick. | 11:56 |
| pitti | that's the problem with keys -- nobody wants to exchange them, but you have to if they get lost, or broken, or stolen | 11:57 |
| pitti | but we don't even have the code to import the current key yet | 11:58 |
| pitti | i. e. we need to get to know the key ID, fetch it from the mirrors, and run it by apt-key | 11:59 |
| tkamppeter | pitti, could we perhaps SRU the package with the key in case Epson replaces it. | 11:59 |
| pitti | or hardcode the keyid, etc. | 11:59 |
| pitti | mvo: ^ is it possible/okay at all to ship third-party GPG keys into the default apt keyring? | 12:00 |
| pitti | mvo: e. g. if we want to support Epson printer drivers from openprinting.org? | 12:00 |
| tkamppeter | The needed info about the key is here: | 12:00 |
| pitti | also, all this would need a FF at this point | 12:00 |
| tkamppeter | https://linux.avasys.jp/drivers/lsb/epson-inkjet/key/fingerprint | 12:01 |
| mvo | pitti: that is possible, if we trust them enough to do that | 12:01 |
| tkamppeter | This link is provided on all driver entry pages for the Epson drivers, like: | 12:01 |
| tkamppeter | http://www.openprinting.org/driver/epson-ep-302/ | 12:02 |
| mvo | if the key needs to be exchanged we need to do a security update for the package | 12:02 |
| tkamppeter | clicking on (Signed) at the download links (it is the same key for all packages). | 12:02 |
| pitti | mvo: what would happen if they replace it with a new key? I guess we can't tell apt right now "require a valid GPG key for this repository", so once the key changes, we'd go back to the simple warning mode, right? | 12:04 |
| pitti | once we start adding third-party keys in Jockey with apt-key, we'd need such a flag, I think | 12:04 |
| mvo | pitti: you can test that in the backend, there is a is_trusted property on the version | 12:06 |
| mvo | pitti: so jockey can just refuse to install packages that are unsinged | 12:06 |
| ogra | mvo, if i create a /usr/share/app-install/channels/maverick-ti-ppa.list (and eula), will that work for the new apturl implementation ? | 12:06 |
| pitti | mvo: ah, nice | 12:06 |
| mvo | pitti: you can also use /etc/apt/trusted.gpg.d/ to put keys in if you want to avoid using apt-key | 12:07 |
| mvo | ogra: it should | 12:07 |
| * ogra would like to just put a favorite .desktop on the TI images that enables the ppa and installs SW | 12:07 | |
| ogra | mvo, how would it get the key ? | 12:07 |
| pitti | mvo: nice, just drop single .gpg keys there? | 12:07 |
| pitti | mvo: thanks, so it seems everything is there from the apt side then | 12:08 |
| mvo | pitti: yep | 12:08 |
| mvo | ogra: just add a mavreick-ti-ppa.key file | 12:09 |
| mvo | ogra: to the same package that ships the other stuff | 12:09 |
| bilalakhtar | If an SRU diverges away from Debian, I should use the version number -Xubuntu0.1 right? | 12:09 |
| bilalakhtar | where X is the debian version number | 12:09 |
| pitti | bilalakhtar: right | 12:09 |
| bilalakhtar | Thanks pitti ! | 12:10 |
| ogra | mvo, in /etc/apt/trusted.gpg.d/ ? | 12:10 |
| mvo | ogra: no, just alongside the .eula and .lsit files | 12:11 |
| ogra | ah, perfect | 12:11 |
| mvo | ogra: in etc it would be enabled by default, that is probably not what you want :) | 12:12 |
| ogra | well, it is :) | 12:12 |
| ogra | the TI specific images should have the TI ppa enabled anywa | 12:12 |
| ogra | y | 12:12 |
| mvo | ogra: oh, in this case, just drop it in the trusted.gpg.d and sources.list.d and don't bother with apturl | 12:12 |
| ogra | so it wont matter ... but its more elegant to have all files in one place | 12:12 |
| ogra | mvo, ti want a favorite .desktop file that holds the package list so i think i need apturl | 12:13 |
| ogra | s/ti/i/ | 12:13 |
| ogra | and i want a sexy way to show the TI eula :) | 12:14 |
| ogra | mvo, btw, thats just awesome ! | 12:14 |
| mvo | ogra: test it first, I'm not sure the eula is implemented in the new world order (but if not its trivial to add) | 12:15 |
| ogra | will do | 12:15 |
| === MacSlow is now known as MacSlow|lunch | ||
| tkamppeter | pitti, did mvo's help give us a solution for the Epson driver download? | 12:28 |
| pitti | tkamppeter: seems apt has all the building blocks that we need, yes; but the actual implementation of key retrieval, installation, and "is_trusted" checking still remains | 12:30 |
| === al-maisan is now known as almaisan-away | ||
| bilalakhtar | pitti: Package cluster-glue is awaiting the queue for getting into -proposed. Looking at the queue, there are many old packages also there, so is there a need to ping a person from the SRU team to get the package in proposed? | 12:58 |
| pitti | bilalakhtar: no, it's mainly a matter for an SRU team person to make some time to review packages | 12:59 |
| pitti | pinging won't really help, I'm afraid | 12:59 |
| pitti | with the freeze being tomorrow, I guess everyone is busy with maverick until then | 12:59 |
| bilalakhtar | pitti: thanks | 12:59 |
| pitti | also, I was on vac last week, which didn't help SRUs either :) | 13:00 |
| === dendrobates is now known as dendro-afk | ||
| === MIH1406_ is now known as MIH1406 | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === almaisan-away is now known as al-maisan | ||
| ari-tczew | cking: ubuntu-security-sponsors unsubscribed | 13:48 |
| === smb-afk is now known as smb | ||
| cking | ari-tczew, thanks, sorry about that | 13:54 |
| ari-tczew | cking: no problem, everyone can do mistake | 13:54 |
| === ivoks-afk is now known as ivoks | ||
| === ivoks is now known as ivoks-afk | ||
| smoser | apw, around ? | 14:51 |
| === xfaf is now known as zul | ||
| apw | smoser, hi | 14:52 |
| smoser | i'm really in need of some help on bug 606373 | 14:52 |
| ubottu | Launchpad bug 606373 in linux (Ubuntu Maverick) "cloud-init output does not get to console when booted with pv-grub and ramdisk" [High,Confirmed] https://launchpad.net/bugs/606373 | 14:52 |
| smoser | i've gotten some second hand info from jjohansen on what we think the problem is and , thus, how we think we could work around it | 14:52 |
| smoser | but i've been unsuccessful in my attempts. | 14:53 |
| apw | smoser, basically you lose the output at random i believe yes ? | 14:54 |
| smoser | well, in my experience random is "only early in boot" | 14:55 |
| smoser | you can see my init wrapper there | 14:55 |
| apw | which would also make sense, if its the issue with the console right? | 14:55 |
| smoser | output to /dev/console just sometimes doesn't get there. | 14:55 |
| apw | from upstart jobs right? | 14:55 |
| smoser | yes, from upstart jobs, but also reproduced in that little /sbin/init replacement (that then exec's upstart). | 14:56 |
| smoser | see the attachment there. | 14:56 |
| smoser | http://launchpadlibrarian.net/55625702/init-wrapper.txt | 14:56 |
| smoser | basically it just forks a process that keeps attempting to open and write to /dev/console every second | 14:56 |
| smoser | and then execs upstart | 14:56 |
| smoser | not all output from the forked process gets to the console. | 14:57 |
| apw | smoser, so that forked process is opening and closing /dev/console repeatedly right (from a quick scan) | 14:57 |
| smoser | in the one i attached, i made sure to close all filehandles of the forked pid. but i've also tested without the closing of FDs (so that a handle on /dev/console would always be open) and got the same results. | 14:58 |
| smoser | apw, yes. | 14:58 |
| apw | so that will definatly hit the issue | 14:58 |
| apw | you should try something like this | 14:58 |
| apw | #!/bin/bash | 14:58 |
| apw | ( | 14:58 |
| apw | sleep 120 </dev/console | 14:59 |
| apw | ) & | 14:59 |
| apw | sleep 1; exec real | 14:59 |
| apw | and see if that sorts it out | 14:59 |
| smoser | i've basically tried that | 14:59 |
| apw | you could also run your currnet debug as a third procerss to confirm it changes things if you get me | 14:59 |
| smoser | that was my first incantination | 14:59 |
| smoser | but in the existing one there, i tested without closing file descriptors | 14:59 |
| smoser | and the forked process, would then inherit stdio, stdin, stderr from the parent | 15:00 |
| smoser | and would, thus, keep a reference open | 15:00 |
| apw | and the parent is connceted to console ? | 15:00 |
| apw | you sure ? | 15:00 |
| apw | thats why i am being explicit in opening the console | 15:00 |
| smoser | ramdisks exec /sbin/init </dev/console > /dev/console 2>&1 | 15:00 |
| smoser | additionally, I *do* get the "hello world" from the parent to the console | 15:00 |
| smoser | we get some output, then it goes away, then we get some more | 15:01 |
| apw | well to avoid the race you have to keep it open | 15:01 |
| apw | if its still going missing with a confirmed open then it may be a differnet bug | 15:01 |
| smoser | well i that forked process does not close it, then it is kept open | 15:01 |
| smoser | so if you imagine that script , but with the following line commented out | 15:02 |
| smoser | exec 1>&- ; exec 0<&-; exec 2>&-; | 15:02 |
| apw | the example in there now does close them | 15:02 |
| smoser | then the original fd is still open | 15:02 |
| smoser | yes | 15:02 |
| apw | right so the example there is useless for avoiding the issue | 15:02 |
| smoser | i tested last night with that commented out also | 15:02 |
| smoser | i can re-test that if you'd like | 15:02 |
| apw | ok then next step ought to be to replace echo with a C program that records the real exit status of open etc and prints them to stderr | 15:03 |
| apw | and retest ... we need to find out if open fails and if write fails and if close fails, and with what | 15:03 |
| apw | for the one that goes missing | 15:03 |
| apw | remembver to 2>>${out} | 15:03 |
| apw | smoser, making sense ? | 15:04 |
| smoser | well, i also have python tests (cloud-init) that tried open() | 15:05 |
| smoser | and did never received failure | 15:05 |
| smoser | but i will try with C | 15:05 |
| smoser | ie, in cloud-init when it ran, i would loop over a try to open("/dev/console") and wait until it succeeded | 15:05 |
| smoser | but i never saw failures | 15:05 |
| apw | well i care not what you test with, but in that context where we see 1 2 4 i want to know if userspace was told there was an issue | 15:05 |
| smoser | and i lost output | 15:05 |
| smoser | right. | 15:06 |
| smoser | so python was not | 15:06 |
| apw | smoser, this is all in ec2 isn't it? | 15:06 |
| apw | or kvm ? | 15:06 |
| smoser | i can probably reproduce in a vm | 15:06 |
| smoser | would you like me to try that ? | 15:06 |
| apw | nope, i want to know where you are testing: "Where is this testing occuring?" | 15:06 |
| smoser | actually, yeah, thats obviously important | 15:06 |
| smoser | as they have different /dev/consoel implementations | 15:06 |
| smoser | what i'm reporting is in ec2 | 15:07 |
| smoser | yes | 15:07 |
| apw | so we have no real idea if we sent the data out or not | 15:07 |
| apw | and ec2 is somewhat nebulous | 15:07 |
| * apw has a look if we could log in the kernel | 15:07 | |
| Chipaca | has python-aptdaemon's api changed since lucid? | 15:13 |
| apw | smoser, what device is console on in ec2? | 15:14 |
| apw | smoser, and have you ever had a report of this outside ec2? | 15:14 |
| smoser | i'm testing on eucalyptus (kvm) now. i dont recall having seen it outside ec2. | 15:15 |
| smoser | console on ec2 is /dev/console, but i believe our kernel is patched so that hvc0 == /dev/console | 15:15 |
| soren | Doesn't EC2 pass console=/dev/ttyS0 ? | 15:16 |
| smoser | no. eucalyptus does | 15:16 |
| soren | Or am I confused? | 15:16 |
| smoser | i can check that, but i dont think so. | 15:16 |
| smoser | we boot with pv-grub now, and our command line does not have that. | 15:16 |
| smoser | but we specify it | 15:16 |
| apw | smoser, what does cat /proc/cmdline say | 15:17 |
| smoser | apw, we started seeing it reproducibly when 2 things changed. a.) ramdisk b.) using pv-grub as the loader rather then xen loading the kernel. | 15:18 |
| apw | smoser, so ... a lot has changed | 15:18 |
| apw | and didn't you change kernels then too? | 15:18 |
| smoser | yes. | 15:18 |
| smoser | lots have changed. we changed from a 'linux-ec2' to a -virtual kernel with pvops also | 15:19 |
| apw | right so basicall we threw out the bathwater, baby, bath, and the house ... so it could be anything | 15:20 |
| apw | so which console driver does it use in this mode# | 15:20 |
| smoser | the console is always been the xen console | 15:20 |
| smoser | /dev/hvc0 | 15:20 |
| apw | ok .... | 15:21 |
| smoser | but no console= command line is passed | 15:21 |
| apw | i am sure that /dev/hcv0 has changed between the kernels in quesion | 15:21 |
| apw | i wonder if we can log what is trying to go out via it in dmesg so you can see if its getting that far | 15:21 |
| smoser | lucid command line: root=/dev/sda1 ro 4 | 15:21 |
| smoser | maverick command line: root=LABEL=uec-rootfs ro | 15:22 |
| smoser | we can control the maverick command line | 15:23 |
| apw | smoser, so you use -virtual yes ? | 15:23 |
| smoser | we could not control it in lucid | 15:23 |
| smoser | lucid uname: 2.6.32-308-ec2 | 15:23 |
| smoser | maverick uname: 2.6.35-21-virtual | 15:23 |
| apw | smoser, so i think i could log everything sent out via the console say at debug level | 15:33 |
| apw | else it would be recursive of course | 15:33 |
| smoser | which woudl get to syslog ? | 15:33 |
| apw | yeah it should i think | 15:33 |
| smoser | hm. | 15:33 |
| smoser | but that might not benefit us | 15:34 |
| smoser | as syslog isn't going to be up until upstart starts it | 15:34 |
| smoser | oh | 15:34 |
| smoser | but there is that buffer for syslog | 15:34 |
| smoser | right ? | 15:34 |
| apw | yeah, it'd be in dmesg | 15:34 |
| smoser | that would be useful i think | 15:34 |
| apw | so we could use that to try and work out if its gets that low or not | 15:34 |
| apw | of course i have no way to debug it | 15:34 |
| apw | ie to test it before hang | 15:34 |
| apw | hand | 15:34 |
| === njpatel_ is now known as njpatel | ||
| slangasek | soren: ah, the networking job; yes, that could cause a problem, indeed | 15:36 |
| === bjf[afk] is now known as bjf | ||
| === ara_ is now known as ara | ||
| smoser | apw, ok, so: http://paste.ubuntu.com/494225/ is console output (the most recent boot) with /sbin/init of http://pastebin.com/q7kE2bbf | 15:43 |
| soren | slangasek: Ok, so if I want a bridge, br0, with a single attached interface, eth0, what's the correct configuration? Do I have an "iface eth0" stanza at all or do I just have an "iface br0" stanza with bridge_ports eth0? What about "auto br0" or "auto eth0"? | 15:43 |
| smoser | for 6 seconds, output to stdout of that forked process went no where. | 15:43 |
| smoser | it went to console, then disappeared for 6 seconds, then returned. | 15:44 |
| === dendro-afk is now known as dendrobates | ||
| === deryck is now known as deryck[lunch] | ||
| apw | cjwatson, Keybuk, does plymouth do anything clever with console output while it is on the screen ? | 16:06 |
| === rgreening_ is now known as rgreening | ||
| Keybuk | apw: lots | 16:07 |
| Keybuk | it takes it and buffers it, and logs it, and redirects it | 16:07 |
| Keybuk | and sometimes adds salt | 16:07 |
| apw | Keybuk, as in /dev/console output ? | 16:07 |
| apw | and if so, how is it getting in the stream ? | 16:08 |
| Keybuk | ioctl | 16:10 |
| apw | urgle so we have a period during boot on ec2 of about 6 seconds around when mountall says its running where there is a gap in console output | 16:11 |
| apw | Keybuk, ^^ might that be expected behaviour with plymouth around | 16:11 |
| Keybuk | err. not sure | 16:12 |
| Keybuk | I don't think so | 16:12 |
| Keybuk | does it go into /var/log/boot.log ? | 16:12 |
| apw | smoser, ^^ ? | 16:12 |
| andreserl | slangasek, howdy!! I talked to upstream about the soname changes in pacemaker, and well he pretty much told me that they are not guaranteed to change, because they will, but that doesn't happen very often (as in bumping versions) | 16:13 |
| smoser | looking | 16:13 |
| smoser | awesome | 16:13 |
| smoser | the lost data (and only the lost data) is in /var/log/boot.log | 16:13 |
| apw | Keybuk, so does that mean that plymouth was running during that period ? | 16:14 |
| Keybuk | Isure | 16:14 |
| apw | Keybuk, do we have any control over whether plymouth repeats its input to the real console, or is it gone while plymouth runs | 16:15 |
| apw | gah wish i understood plymouth better | 16:15 |
| Keybuk | yes, plymouth plugins dictate which does what | 16:16 |
| cjwatson | plymouth's details plugin is supposed to repeat things to the real console | 16:16 |
| cjwatson | (src/plugins/splash/details/plugin.c) | 16:16 |
| apw | smoser, is your missin init script output in there? | 16:16 |
| apw | as well as the debug? | 16:17 |
| cjwatson | it may not display anything if it thinks it's waiting for the answer to a question | 16:17 |
| smoser | apw, yes. | 16:17 |
| smoser | its all there. | 16:17 |
| smoser | cjwatson, where would i see an indication that plymouth would be waiting for an answer to a question ? | 16:18 |
| Wubbbi | Hey guys. Can someone confirm the white screen that I get after logging in in uptodate Maverick Netbook? I cant use it anymore. Update on way? | 16:18 |
| smoser | filesystem will be clean (pristine image boot) | 16:18 |
| cjwatson | smoser: if it were, it ought to be the last visible line on the console | 16:19 |
| apw | i can't think of any questions it migth be asking though it might be offering cancel for fsck's i guess ? for the shortest time | 16:19 |
| smoser | not htere. | 16:19 |
| cjwatson | Wubbbi: you're not the first person to report that today, but I don't do any netbook work myself so I know no more than that | 16:19 |
| smoser | not there. | 16:19 |
| apw | and anyhow we lose it for 6 seconds which sounds likely to be 'all' of the time plymouth is active during a boot ? | 16:19 |
| apw | peraps the repeating just isn't working, disabled perhaps | 16:20 |
| Wubbbi | Hmmm ... ok. But you must understand, that I cant use my Netbook now anymore. Well I can go to init 3 and do updates but no working. Well I know its Beta. I just wanted to tell you that this is a emergancy issue! :) | 16:20 |
| zyga | ubuntu just got first spam blueprint | 16:21 |
| zyga | https://blueprints.edge.launchpad.net/ubuntu/+spec/new-background-ubuntu | 16:21 |
| smoser | apw, i did sudo sh -c 'for x in /etc/plymouth*.conf; do mv $x $x.disabled; done' | 16:23 |
| smoser | then reboot | 16:23 |
| smoser | http://paste.ubuntu.com/494238/ | 16:23 |
| smoser | the console log now has everything | 16:23 |
| ogra_ac | zyga, we have a ton of spam blueprints already | 16:23 |
| ion | zyga: That’s not spam, it’s just trolling. | 16:23 |
| * zyga didn't know | 16:23 | |
| apw | smoser, i think that points squarly at plymouth then, especially as it itself logs the missing data as well | 16:24 |
| smoser | i think so too :) | 16:24 |
| apw | Wubbbi, fingers are being point at a mesa update | 16:24 |
| apw | Wubbbi, see discussion on #ubuntu-x | 16:24 |
| Wubbbi | apw: Will this mesa update fix it or do you want to say that there is no time to fix the white screen issue? | 16:27 |
| Wubbbi | Well even I want to thank you guys. I know more now ^^ | 16:27 |
| === lag is now known as lksjopfjljfslijg | ||
| === lksjopfjljfslijg is now known as jigijigijigjijig | ||
| === jigijigijigjijig is now known as lag | ||
| apw | smoser, so do we need plymouth at all ? | 16:40 |
| cjwatson | $ ldd /sbin/mountall | grep libply | 16:40 |
| cjwatson | libply.so.2 => /lib/libply.so.2 (0x00742000) | 16:40 |
| cjwatson | libply-boot-client.so.2 => /lib/libply-boot-client.so.2 (0x009ec000) | 16:40 |
| === dendrobates is now known as dendro-afk | ||
| cjwatson | i.e. yes | 16:40 |
| smoser | so, someone want to point me at plymouth where it should be repeating stuff to /dev/console ? | 16:41 |
| cjwatson | I did above | 16:42 |
| cjwatson | search back for 'details' | 16:42 |
| tkamppeter | pitti, WDYT should we do with Epson then? | 16:43 |
| sladen | jono: around? | 16:43 |
| === yofel_ is now known as yofel | ||
| apw | smoser, do we even have a graphical display on an ec2 instance... is there any point in running plymouth at all ? | 16:44 |
| smoser | no. | 16:44 |
| smoser | other than the world depends on it. | 16:45 |
| cjwatson | plymouth is what gives you boot logging | 16:45 |
| cjwatson | it will be much easier to fix it than to excise it | 16:45 |
| smoser | yeah. so looking. | 16:45 |
| smoser | so anyone suggest why i would see this on ec2 and not on eucalyptus ? | 16:50 |
| smoser | other than just unlucky timing ? | 16:50 |
| === dendro-afk is now known as dendrobates | ||
| === deryck[lunch] is now known as deryck | ||
| james_w | juliank: hi, is it possible with python apt to find out /why/ the packages are broken if cache.broken_count > 0 | 17:02 |
| james_w | juliank: I've found how to find which packages are broken, but I'm confused as to why they are broken in this case | 17:03 |
| juliank | james_w: Probably not via apt.* API, only via apt_pkg API. | 17:05 |
| james_w | juliank: that's fine for now, I'm just debugging right how | 17:05 |
| james_w | now | 17:05 |
| james_w | I think it's to do with Provides, but I can't reproduce in a test case, so I'm a little lost | 17:06 |
| james_w | thanks for writing the docs though, it's helped me get this far | 17:07 |
| juliank | james_w: You have to go through the reverse dependencies and check for conflicts/breaks there and go through the installed version's dependencies and check which one is not installed. | 17:07 |
| juliank | If you don't need code, running aptitude why/why-not might make more sense. | 17:08 |
| james_w | juliank: I'm doing something similar to chdist, but with "install" functionality which pretends that particular packages are installed by writing them to /var/lib/dpkg/status | 17:08 |
| james_w | juliank: it works in my tests, but using on the Ubuntu archive leads to broken packages after "installing" the packages and reloading the cache. | 17:09 |
| james_w | I've printed out the Depends/PreDepends/Conflicts for each broken package, and checked them against what was installed, and it looks like virtual packages are the problem, as Provides isn't currently written to /var/lib/dpkg/status | 17:10 |
| juliank | james_w: Then why not just write the provides? | 17:11 |
| james_w | juliank: that's what I'm going to do, but I want a test case to confirm my hunch first | 17:11 |
| === al-maisan is now known as almaisan-away | ||
| bilalakhtar | iulian: pign | 17:15 |
| dmart | Keybuk: hi--- not sure if you had a chance to look yet, but I had some thoughts on the rpc.statd issue | 17:15 |
| bilalakhtar | *ping | 17:15 |
| dmart | Keybuk: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/525154 if you want to take a look | 17:15 |
| ubottu | Launchpad bug 525154 in nfs-utils (Ubuntu) "mountall for /var races with rpc.statd" [Undecided,Triaged] | 17:15 |
| === dendrobates is now known as dendro-afk | ||
| Keybuk | dmart: it's not something I'm particularly looking at | 17:19 |
| apw | cjwatson, if during a dist-upgrade a package is held back ... how do i find out why its held back | 17:19 |
| dmart | Keybuk: any idea who is? I think you and slangasek were the main people to have commented... | 17:20 |
| Keybuk | I don't think anyone is | 17:20 |
| apw | cjwatson, ahh found it, the armel binaries are still in binary new .... i wonder if we could tickle those | 17:21 |
| dmart | Keybuk: it does look like it bites people using a resonably common server configuration, though I can work around it for myself | 17:21 |
| dmart | My concern was around the fact that it seems impossible to express the correct start conditions for statd in upstart, and that this limitation may be affecting other things too. | 17:22 |
| slangasek | soren: for a bridge, I don't know that you need any 'iface eth0' stanza at all; the 'iface br0' + 'bridge_ports eth0' + 'auto br0' seems to be enough, unless your eth0 needs other configuration | 17:22 |
| Keybuk | dmart: it may indeed be impossible with the current upstart | 17:23 |
| juliank | james_w: I have to be away for ~ 10 minutes now | 17:23 |
| ogra_cmpc | lets switch back to sysvinit then | 17:23 |
| ogra_cmpc | its still time before release :P | 17:23 |
| slangasek | andreserl: so that means your package name for all of libpacemaker would need to change for each of those soname changes, and Conflict: with the prior package name; not pretty, but seems to be the best option | 17:24 |
| Keybuk | ogra_cmpc: <censored reply> | 17:24 |
| ogra_cmpc | heh | 17:24 |
| slangasek | andreserl: in that case I think you should get a serial included in the libpacemaker package name up front (e.g., libpacemaker0 or libpacemaker1; doesn't matter what) | 17:25 |
| Keybuk | though | 17:25 |
| Keybuk | I can't possibly be upset today | 17:25 |
| Keybuk | today is a GOOD DAY | 17:25 |
| Keybuk | http://lists.fedoraproject.org/pipermail/devel/2010-September/142858.html | 17:25 |
| dmart | Keybuk: anyways, there are some thoughts from me in the bug thread about how the problem could be solved ... but unfortunately I don't really have time to try it out just now, I just hit it as a side-issue. | 17:25 |
| Keybuk | jonmasters: how the hell did that summon you? :p | 17:25 |
| ogra_cmpc | poor lennart | 17:26 |
| ogra_cmpc | heh | 17:26 |
| slangasek | dmart: rpc.statd> on my list, I guess; though I don't know that I'm going to be able to get anywhere with really solving the outstanding nfs-utils upstart bugs until the new upstart features land | 17:27 |
| ogra_cmpc | Keybuk, did you tell him that we are hiring an OO.o maintiner ? *g* | 17:27 |
| ogra_cmpc | in case he wnats to leave fedora | 17:27 |
| Keybuk | we could do with a pulse audio maintainer | 17:27 |
| ogra_cmpc | we surely could, yeah | 17:28 |
| dmart | slangasek, Keybuk: is there a wiki / tasklist for upstart features I could look at? I'd be interested | 17:28 |
| Keybuk | dmart: nope | 17:29 |
| dmart | oh well | 17:30 |
| === ivoks-afk is now known as ivoks | ||
| james_w | juliank: I'm not seeing any way to get the Provides information for a given package, is there one? | 17:40 |
| james_w | oh, provides_list in apt_pkg seems to be it | 17:41 |
| andreserl | slangasek, the other option would be to move them back to pacemaker package itself, since those libraries are only for pacemaker itself | 17:42 |
| slangasek | andreserl: if they're only for pacemaker, why were they split out at all? I thought this was because they would be dependencies of redhat-cluster? | 17:43 |
| apw | slangasek, you wouldn't be able to stroke a linux through binary new would you? armel only seems to be caught there | 17:44 |
| andreserl | slangasek, right now, redhat-cluster depends on pacemaker-dev (I just checked), so the split was to make them dependant on libpacemaker-dev | 17:44 |
| andreserl | slangasek, either way, we'll be disabling pacemaker's support in redhat-cluster given that cluster-glue won't be in shape, so I'd rather have redhat-cluster without pacemaker's support to not FTBFS | 17:47 |
| slangasek | apw: yes, will grab it this morning | 17:47 |
| slangasek | andreserl: so, I guess I don't understand the point of splitting pacemaker-dev and having redhat-cluster build-depend on libpacemaker-dev, if it wasn't going to use the libs | 17:48 |
| ogra_cmpc | i dont get why armel is the only arch hanging there | 17:48 |
| slangasek | seems like a pointless split to me | 17:48 |
| ogra_cmpc | the i386 and amd64 binaries seem to not have that issue | 17:48 |
| apw | slangasek, that being there looks to be breaking upgrades, and i'd like to know it is only that ... as we'd like to fold any fix into todays upload which was planned for a couple of hours | 17:49 |
| === roaksoax__ is now known as andreserl | ||
| NCommander | cjwatson: kirkland: ping, I need your archive foo: can you please release the linux/armel binaries? | 17:53 |
| juliank | james_w: Yes, Package.provides_list [which versions provide this package] always works (and for the opposite view [what does this version provide] Version.provides_list) | 17:53 |
| andreserl | slangasek, the idea was to make the package policy compliant for the libraries to get the MIR accepted, but since we are almost in FinalFreeze and unfortunately who's working on cluster-glue couldn't make it on time, we are also dropping pacemaker's support for RCHS | 17:53 |
| RoAkSoAx | slangasek: /win 6 | 17:53 |
| james_w | juliank: yeah, the latter is what I wanted, thanks. It indeed fixes the problem, but I have no idea why I can't reproduce it in a test case yet | 17:53 |
| RoAkSoAx | ups | 17:53 |
| ogra_cmpc | NCommander, that was discussed ten mins ago | 17:54 |
| slangasek | andreserl: well, I don't think the changes that were made here have any bearing on policy compliance | 17:54 |
| jonmasters | Keybuk: explain summon me? | 17:54 |
| andreserl | slangasek, we wanted to separate the libraries from the binaries | 17:54 |
| * ogra_cmpc suggest to read backlog to NCommander before asking questions ;) | 17:55 | |
| slangasek | especially creating a libpacemaker-dev package that will be used as a build-dependency for only one package that doesn't use the libs | 17:55 |
| Keybuk | jonmasters: I pasted a fedora-devel-list mail url and you literally appeared straight after | 17:55 |
| slangasek | andreserl: which, unless it's done in a forwards-compatible way, is worse than /not/ splitting it | 17:55 |
| slangasek | apw: accepted | 17:55 |
| jonmasters | Keybuk: oh weird, maybe my client temporarily lost connection | 17:55 |
| dpm | hi pitti, is there any way to see if the language packs are building? I'm looking here: https://edge.launchpad.net/ubuntu/+builds?build_text=language-pack&build_state=all, but I don't see any and I'm not sure if there is a better way to find out | 17:55 |
| jonmasters | Keybuk: I got a text message though when you mentioned my name ;) | 17:56 |
| * NCommander hides his head | 17:56 | |
| andreserl | slangasek, I agree, I now know that each library should have been split in their own package if we wanted to do the split, but now that I've talked with usptream about this, it's agreed that those libraries are only used by pacemaker and there would be no need to spliut the packages | 17:57 |
| apw | slangasek, thanks you are a star, its all frantic over here | 17:57 |
| pitti | dpm: lemme check | 17:57 |
| slangasek | andreserl: great, sounds like we're now on the same page then :) | 17:58 |
| === MacSlow is now known as MacSlow|break | ||
| pitti | dpm: hm, they were built, but upload failed | 17:59 |
| pitti | KeyError: 'getpwuid(): uid not found: 2009' | 17:59 |
| andreserl | slangasek, :). I'll roll back the changes and do a new upload | 17:59 |
| pitti | hmm | 17:59 |
| kirkland | NCommander: looking .... | 18:00 |
| pitti | dpm: uploading now | 18:00 |
| pitti | dpm: weird, it works when I run it manually, but not from cron | 18:00 |
| dpm | pitti, ok thanks | 18:00 |
| apw | does anyone know if i can rely on these two version number comparing equal: 2.6.35-22.11 2.6.35-022.11 | 18:13 |
| juliank | apw: The 0 is dropped, so yes. | 18:14 |
| apw | thanks | 18:14 |
| juliank | apw: That also means: "1.0-0" = "1.0" = "1." = "1.-0" = "1.-" | 18:20 |
| Keybuk | errrrr | 18:21 |
| Keybuk | that's wrong | 18:21 |
| apw | juliank, are you sure about that | 18:21 |
| apw | i don't read the explanation as saying that at least | 18:21 |
| tumbleweed | he definitly is :P | 18:21 |
| Keybuk | it's correct that -22.11 and -022.11 are equivalent | 18:22 |
| apw | i see it saying that they are compared numerically, but that only the empty string at the end can be compared as 0 | 18:22 |
| Keybuk | but 1.0-0 and 1.0 are NOT equivalent | 18:22 |
| Keybuk | neither are 1. and 1.0 | 18:22 |
| tumbleweed | http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version | 18:22 |
| juliank | Keybuk: They are | 18:22 |
| apw | 022 and 22 are both converted to 22 arn't they | 18:22 |
| Keybuk | no they're not | 18:22 |
| Keybuk | I wrote the current edition of the code in dpkg | 18:22 |
| Keybuk | I'm pretty sure I know of what I speak | 18:22 |
| smoser | $ dpkg --compare-versions 1.0-0 eq "1.-0" && echo y | 18:22 |
| smoser | y | 18:22 |
| juliank | Keybuk: Try it yourself. | 18:22 |
| smoser | that is the definitive guide | 18:22 |
| juliank | jak@jak-thinkpad:~$ dpkg --compare-versions 1.0 eq 1. && echo y | 18:22 |
| juliank | y | 18:22 |
| Keybuk | huh | 18:23 |
| Keybuk | someone's changed it then | 18:23 |
| Keybuk | because they shouldn't be | 18:23 |
| apw | that doesn't match the description in the policy manual for sure | 18:23 |
| Keybuk | 1.0-0 and 1.0 are different bases, one has a revision, one doesn't | 18:23 |
| juliank | Keybuk: It's valid according to the policy | 18:23 |
| apw | Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. | 18:23 |
| apw | ^ from the policy | 18:24 |
| juliank | 0 means empty string. No revision means empty revision string => 0 revision is equal to no revision | 18:24 |
| apw | i'd say that says that the empty string should only compare at the end of the string | 18:24 |
| Keybuk | right, you're not supposed to insert arbitrary empty in there | 18:24 |
| juliank | Keybuk: Also, Policy states "The absence of a debian_revision is equivalent to a debian_revision of 0" | 18:24 |
| apw | i am not sure from the policy how they should compare of course | 18:24 |
| Keybuk | I guess 1.-0 comes out as | 18:25 |
| Keybuk | <1><.><0><-><0> | 18:25 |
| Keybuk | where the 0 gets implied, but dpkg never behaved that way | 18:26 |
| Keybuk | does look like someone's tried to match the two together | 18:26 |
| juliank | Keybuk: In practice, 1.0-0 becomes "1.-" in the parser, as it drops 0 at the beginning | 18:26 |
| apw | then the parse definatly does not implement the words in the policy | 18:27 |
| apw | regardless of which makes more sense | 18:27 |
| lamont | Keybuk: there was a policy change recently that made 1.0 == 1.0-0 | 18:27 |
| juliank | apw: It does effectively. You can strip any zeros in front of a number without modifying the numbers value. | 18:27 |
| lamont | for some value of recently | 18:27 |
| Keybuk | juliank: you can strip zeros, yes, but you can't strip all zeros | 18:28 |
| Keybuk | you're only supposed to strip from the beginning and end of the string, not in the middle | 18:28 |
| juliank | Keybuk: Yes, it just strips those in front of a digit sequence. | 18:28 |
| Keybuk | otherwise you could end up with 1.0.0-0 becoming 1..- | 18:28 |
| Keybuk | juliank: that's wrong, then | 18:28 |
| juliank | Keybuk: 1.0.0.0-0 is 1..- | 18:28 |
| Keybuk | juliank: it *shouldn't* be | 18:28 |
| Keybuk | go read policy carefully | 18:28 |
| apw | the policy does tell you that it should only occur at the end of the string | 18:29 |
| Keybuk | because then madness ensues | 18:29 |
| apw | but it also doesn't tell you how to compare 1.. and 1.0.0 | 18:29 |
| sladen | http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version for reference, since I happened to paste it somewhere else a minute ago | 18:29 |
| andreserl | slangasek, btw, can you please take a look to bug #527195 and leave your comment on the library split, as we are going to retarget it for natty? :) Thank you! | 18:30 |
| ubottu | Launchpad bug 527195 in pacemaker (Ubuntu) "[MIR] pacemaker" [Undecided,Incomplete] https://launchpad.net/bugs/527195 | 18:30 |
| juliank | Keybuk: or not, but that seems to be a bug | 18:30 |
| apw | sladen, yep same as whats in the ubuntu policy manual which leaves it undefined by stating it cannot occur | 18:30 |
| juliank | Keybuk: OK, you're right in this point. | 18:31 |
| Keybuk | this is deeply digressing from the fact that 22 and 022 are always equivalent in dpkg, of course | 18:31 |
| juliank | 1.0.0.0-0 is not 1... | 18:31 |
| apw | Keybuk, yeah, i may want to rely on that | 18:31 |
| juliank | - | 18:31 |
| Keybuk | apw: you certainly can rely on that | 18:31 |
| apw | Keybuk, thanks for that | 18:31 |
| apw | interestingly the policy does not say strip the 0's simply that a string of digits is copared using its decimal value | 18:32 |
| juliank | Keybuk: The most straight-forward implementation of policy is http://git.debian.org/?p=users/jak/apt2.git;a=blob;f=systems/deb/debversion.c;h=07575615e9bfb60ab4627ba6ab65dbe4e535baf0;hb=HEAD (it's closer to the wording than dpkg's one, but yields the same results) | 18:32 |
| MIH1406 | Hi, I want to get a degree in programming what is the best program for that? "Computer Science", "Software Engineering" or what? | 18:33 |
| juliank | (I wrote it because I wanted an LGPLed codebase) | 18:33 |
| dpm | pitti, quick question: on bug 66550, can you think of anything obvious that might be missing in order to let the language entry appear in the gdm menu? | 18:35 |
| ubottu | Launchpad bug 66550 in Ubuntu Translations "Yoruba language not shown in gdm menu" [Medium,Triaged] https://launchpad.net/bugs/66550 | 18:35 |
| juliank | And it behaves identically compared to APT when comparing all versions in Debian unstable against each other (although a bit faster) | 18:35 |
| pitti | dpm: does that still happen? this obviously was reported against the old gdm (2.20 and earlier) | 18:35 |
| pitti | dpm: otherwise no, I don't know off-hand how gdm reads the langauge list | 18:35 |
| dpm | pitti, the original reporter said that this is still happening in maverick. In any case, I just wanted to know if it might be something obvious. Thanks | 18:37 |
| pitti | dpm: looking at gui/simple-greeter/gdm-languages.c, it seems to read the available locales | 18:38 |
| pitti | i. e. it should be in locale -a | 18:38 |
| pitti | more precisely, it's parsing /usr/lib/locale/locale-archive, but so does locale -a | 18:38 |
| dpm | pitti, ok, thanks. I'll try to install yoruba and see what happens then | 18:39 |
| pitti | good night everyone! | 18:41 |
| dpm | night pitti! | 18:41 |
| iulian | bilalakhtar: What can I do for you? | 18:42 |
| iulian | bilalakhtar: Just to let you know, I usually don't respond to contentless pings. | 18:42 |
| bilalakhtar | iulian: bug #639631 | 18:42 |
| ubottu | Launchpad bug 639631 in gworldclock (Ubuntu) "[FFe] Please merge gworldclock 1.4.4-9 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/639631 | 18:42 |
| bilalakhtar | since a user just asked for the fix, sorry | 18:42 |
| bilalakhtar | the fix which is in that merge | 18:43 |
| * iulian looks. | 18:43 | |
| bilalakhtar | was trying to save time and avoid tomorrow's freeze | 18:43 |
| bilalakhtar | since the merge is ready | 18:44 |
| bilalakhtar | just needed that exception | 18:44 |
| iulian | bilalakhtar: Approved. Please upload. | 18:45 |
| bilalakhtar | Thank a lot, iulian ! | 18:46 |
| iulian | No problem. | 18:46 |
| Keybuk | juliank: http://bazaar.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/annotate/head:/deb/version.py | 18:49 |
| Keybuk | I wrote that ages ago ;P | 18:49 |
| Chipzz | Keybuk: I was reading your explanantion about upstart yesterday, and tbh, that looks pretty bad | 18:52 |
| Chipzz | I mean, assuming that a service will start when you run "start service" is not unreasonable | 18:52 |
| Chipzz | but apparently that's a broken assumption? | 18:52 |
| Chipzz | I think that will come as a very big surprise to a lot of sysadmins... | 18:53 |
| Keybuk | well, it is a bug | 18:54 |
| andreserl | slangasek, btw.. just uploaded a new pacemaker rev rolling back the library split. Thanks for the help :) | 19:05 |
| jdstrand | cjwatson: are you a moderator for technical-board@? I sent something a couple of days ago, but was told 'Post by non-member to a members-only list' | 19:11 |
| jdstrand | cjwatson: if so, would you mind approving it? | 19:11 |
| jdstrand | cjwatson: and hi btw :) | 19:12 |
| Chipzz | Keybuk: are there any plans to fix the upstart design in that regard? | 19:13 |
| Keybuk | yes | 19:13 |
| Chipzz | great :) | 19:13 |
| === MIH1406_ is now known as MIH1406 | ||
| === MacSlow|break is now known as MacSlow | ||
| === ivoks is now known as ivoks-afk | ||
| slangasek | andreserl: followed up on bug #527195 | 19:57 |
| ubottu | Launchpad bug 527195 in pacemaker (Ubuntu) "[MIR] pacemaker" [Undecided,Incomplete] https://launchpad.net/bugs/527195 | 19:57 |
| andreserl | slangasek, thank you! :) | 19:59 |
| zedtux | Hello all, I'm trying to package into a Ubuntu/Debian package my python app. The package generation work fine, but the package install my app in /usr/lib/python2.6/site-packages/ instead of /usr/lib/python2.6/dist-pacakges | 20:00 |
| zedtux | I don't really know how to fix it. I already have try with --install-layout=deb, that install my app with the python setup.py install, but package continue to install in site-packages... | 20:00 |
| zedtux | I've followed the guide https://wiki.ubuntu.com/PackagingGuide/Python | 20:01 |
| zedtux | and I'm using ubuntu 10.10 | 20:01 |
| zedtux | help ? :) | 20:09 |
| === almaisan-away is now known as al-maisan | ||
| mathiaz | Is there an automated way in LP to ask for no-op package rebuild (ie to pick a newer .so library)? | 20:15 |
| mathiaz | Or the package still need to be uploaded to LP? | 20:15 |
| mathiaz | SpamapS: ^^ | 20:15 |
| iulian | zedtux: Hi there. I believe that #ubuntu-packaging is a better place to ask such questions. #debian-python on OFTC is also a great place for Python packaging. | 20:15 |
| zedtux | Thanks you iulian for your answer :) | 20:16 |
| iulian | You're welcome. | 20:16 |
| SpamapS | mathiaz: as long as you're looking for stuff to sponsor.. bug 638401 would be a good one. :) | 20:19 |
| ubottu | Launchpad bug 638401 in php5 (Ubuntu) "automated tests run during build fail due to apparmor protections for mysqld unless build is done in /tmp" [High,Triaged] https://launchpad.net/bugs/638401 | 20:19 |
| soren | slangasek: Ta very much. | 20:31 |
| smoser | cjwatson, around ? I have an understanding of what was going on with my console bug, and wanted some plymouth advice. | 20:38 |
| * slangasek waves the plymouth flag | 20:43 | |
| slangasek | soren: so does that /work/, or are you thanking me for confirming the nature of a bug? :-) | 20:44 |
| soren | slangasek: The latter. | 20:44 |
| soren | slangasek: He destroyed the evidence. He reinstalled and stuff works now. | 20:44 |
| soren | slangasek: So we'll never know what was wrong. I just wanted to make sure he was doing things by the book before we started ripping everything apart to find the problem. | 20:45 |
| SpamapS | mathiaz: why did you mark bug 620441 as in progress again? Its awaiting sponsorship. | 20:46 |
| ubottu | Launchpad bug 620441 in mysql-dfsg-5.1 (Ubuntu Maverick) "MySQL upstart stop job does not cleanly shutdown mysql" [High,In progress] https://launchpad.net/bugs/620441 | 20:46 |
| mathiaz | SpamapS: yeah - it's in progress | 20:46 |
| mathiaz | SpamapS: IIRC it was in triaged | 20:46 |
| mathiaz | SpamapS: I'm currently building mysql | 20:47 |
| SpamapS | mathiaz: with UDD, should we leave the bug assigned to ourselves even after the merge proposal? | 20:47 |
| mathiaz | SpamapS: I think so | 20:47 |
| mathiaz | SpamapS: as you did most of the work | 20:47 |
| mathiaz | SpamapS: it also shows that you're responsible for getting the bug to a 'Fix released' state | 20:48 |
| slangasek | soren: ah, ok | 20:48 |
| SpamapS | with "old style" sponsorship, I would unassign and mark confirmed | 20:48 |
| mathiaz | SpamapS: doing the sponsorship is secondary and IMO shouldn't change bug assignement | 20:48 |
| SpamapS | mathiaz: I like it, and will change my procedure from now on. | 20:51 |
| SpamapS | mathiaz: I will be offline for a couple of hours, anything else before I go? | 20:52 |
| === al-maisan is now known as almaisan-away | ||
| slangasek | smoser: that plymouth flag was waved for your benefit, fwiw :) | 20:56 |
| kenvandine | lamont, could you please rescore https://edge.launchpad.net/ubuntu/+source/ubuntu-netbook-default-settings/0.8.6/+build/1961558 | 20:56 |
| smoser | slangasek, thanks | 20:56 |
| smoser | :) | 20:56 |
| smoser | funny | 20:56 |
| kenvandine | it is the work around for the mesa bug/train wreck breaking UNE | 20:56 |
| smoser | well, here, let me hit 'submit' on this bug and point you at the comment. | 20:56 |
| smoser | slangasek, https://bugs.edge.launchpad.net/ubuntu/+source/cloud-init/+bug/606373 | 20:57 |
| ubottu | Launchpad bug 606373 in linux (Ubuntu Maverick) "cloud-init output does not get to console when booted with pv-grub and ramdisk" [High,Confirmed] | 20:57 |
| slangasek | smoser: ah; can't provide any specific advice there. You've looked at the code? | 20:59 |
| smoser | a bit. i see where it is looking at console= and doing things based on that. | 21:00 |
| slangasek | smoser: I'm wary of trying to use "/dev/console" in place of a specific device, ISTR there are special semantics involved there - but Keybuk is the expert | 21:00 |
| smoser | i was hoping that i could tell 'details' plugin that 'hey, even though i didn't put console= on the command line, i'd still like to see details' | 21:01 |
| smoser | :) | 21:01 |
| slangasek | oh, by default (on a system with fbcon), you get the details without having any explicit console= line | 21:01 |
| slangasek | so that's not the issue per se | 21:01 |
| slangasek | but it does this by sending it to a vt, and you definitely don't have vts here... | 21:02 |
| smoser | i have to look more at that. | 21:09 |
| achiang | mathiaz: did you ever figure out your LP "no-op rebuild" question? | 21:10 |
| achiang | mathiaz: i'd like to be able to do that too occasionally | 21:10 |
| SpamapS | seems to me that LP could simply trigger noop rebuilds whenever a new version of a -dev lib is uploaded. | 21:13 |
| smoser | SpamapS, in a perfect world, yes. | 21:15 |
| smoser | in one with limited hardware, hm... | 21:16 |
| achiang | i wouldn't mind a manual process, but afaik there's simply no way to do it without bumping the package version and doing a new upload | 21:16 |
| smoser | slangasek, well, it looks like i can run plymouthd with --tty=<string> | 21:26 |
| slangasek | smoser: sure; but that hardly seems better / more maintainable than setting console= on the kernel commandline | 21:27 |
| smoser | right. | 21:27 |
| smoser | and i doubt that i can specify (and have it work) --tty=/dev/console | 21:27 |
| smoser | as it is trapping /dev/console.. might go recursive | 21:28 |
| smoser | thanks for help, slangasek | 21:28 |
| slangasek | smoser: but --tty=/dev/hvc0, maybe? | 21:29 |
| smoser | yeah, but no better as you said. | 21:29 |
| smoser | and then, its hard coded in the image and wouldn't work for uec (where i want tty=ttyS0) | 21:29 |
| smoser | so, i think i'm going to have to boot with console=hvc0 | 21:30 |
| smoser | that, or, mv /etc/init/plymouth.conf /etc/init/plymouth.conf.disabled | 21:30 |
| smoser | (which does work in both places) | 21:30 |
| cjwatson | jdstrand: done | 22:11 |
| jdstrand | cjwatson: thanks! | 22:11 |
| === tkamppeter_ is now known as tkamppeter | ||
| * cyphermox goes back home | 23:34 | |
| SpamapS | mathiaz: have you had more time to think about libdbi? | 23:41 |
| tkamppeter | Can someone check the upload server upload.ubuntu.com? I get always [Errno 111] Connection refused. Worked half an hour ago. | 23:45 |
| TheMuso | tkamppeter: Just trying to upload packages now, and I get the same thing. | 23:46 |
| TheMuso | Oh well, I'll just get all the packages I need to upload into a queue dir. | 23:46 |
| tkamppeter | TheMuso, I need to upload a package still before Final Freeze. | 23:47 |
| TheMuso | So do I. | 23:47 |
| Laney | are you guys trying ftp or sftp or both? | 23:48 |
| TheMuso | ftp | 23:49 |
| * Laney will try sftp | 23:49 | |
| ajmitch | otherwise it's emergency LP ping time? | 23:49 |
| tkamppeter | I use dput. Do not know what dput uses. | 23:49 |
| Laney | dput uses whatever your configuration tells it to | 23:49 |
| Laney | ftp by default | 23:49 |
| TheMuso | dput uses ftp by default. | 23:49 |
| Laney | Unable to connect to SSH host upload.ubuntu.com; EOF during negotiation | 23:51 |
| * Laney tries ppa.lp | 23:51 | |
| mathiaz | SpamapS: hey - yes | 23:54 |
| mathiaz | SpamapS: so I'd lean towards not doing anything for maverick for the following reasons: | 23:54 |
| mathiaz | SpamapS: 1. if we'd updated libdbi we'd have to rebuild a set of packages | 23:54 |
| mathiaz | SpamapS: and that would increase our delta with debian | 23:54 |
| tkamppeter | Upload server returned to work. Upload successful. | 23:54 |
| mathiaz | SpamapS: 2. Nothing is broken in the archive now | 23:55 |
| Laney | I wonder what I just uploaded to ¬_¬ | 23:55 |
| mathiaz | SpamapS: so the tradeoff is that we may break 3rd party apps | 23:55 |
| SpamapS | mathiaz: the delta with debian is temporary. I've been working heavily w/ the maintainer, and he's ready to import what we do. | 23:55 |
| mathiaz | SpamapS: that would mostly be server side apps | 23:55 |
| mathiaz | SpamapS: are you refering to the libdbi maintainer? | 23:55 |
| SpamapS | Yeah, Thomas Goirand | 23:56 |
| mathiaz | SpamapS: because if we rebuild all other packages, we'd *also* have to get their respective debian maintainers | 23:56 |
| psusi | cjwatson, hey! looks like debian fixed the dmraid issue, AND the memory leak: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594221 | 23:56 |
| ubottu | Debian bug 594221 in grub-common "Broken DMRAID support in grub-probe" [Important,Open] | 23:56 |
| mathiaz | SpamapS: so I'd suggest we wait for the transition to happen in Debian | 23:56 |
| mathiaz | SpamapS: 3. we're a bit too late in the release cycle for maverick | 23:57 |
| mathiaz | SpamapS: we'd have to test that all rebuilds would actually work | 23:57 |
| SpamapS | Can we expect it to go into maverick.1 ? Or is this going to have to be a backport? | 23:57 |
| SpamapS | I think 3rd parties will accept the backport | 23:58 |
| mathiaz | SpamapS: there isn't any maverick.1 - or are you refering to natty? | 23:58 |
| SpamapS | mathiaz: I already tested all of the rebuilds | 23:58 |
| SpamapS | but I agree | 23:58 |
| SpamapS | its late | 23:58 |
| SpamapS | archive is not "broken" | 23:58 |
| mathiaz | SpamapS: yeah - if we were earlier in the cycle I'd sponsor it. | 23:59 |
| SpamapS | Would be awesome if we could have both (libdbi-dev and libdbi0-dev) available so at least developers could choose. | 23:59 |
| mathiaz | SpamapS: but IMO we're a bit late for the maverick cycle | 23:59 |
| SpamapS | Realistically though... | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!