| ari-tczew | bdrung: Pushed up to revision 4. | 00:03 |
|---|---|---|
| bdrung | ari-tczew: what did you push? | 00:03 |
| ari-tczew | bdrung: me? nothing. that's sponsor-patch | 00:03 |
| bdrung | ari-tczew: that comes from bzr | 00:04 |
| ari-tczew | bdrung: did I contribute to u-d-t today? | 00:06 |
| ari-tczew | yay! it works! | 00:11 |
| * ari-tczew gives a beer for bdrung and tumbleweed | 00:11 | |
| ari-tczew | bdrung, tumbleweed: sponsor-patch created this branch: https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/cnetworkmanager/natty-201012220015 | 00:17 |
| bdrung | ari-tczew: please file a bug. bzr push needs to be more intelligent | 00:18 |
| ari-tczew | bdrung: tomorrow. I have to go to bed. bye | 00:18 |
| bdrung | ari-tczew: you contributed with two (or three) bug reports | 00:18 |
| === sk0rv is now known as skorv | ||
| pasteeater | siretart: ping | 01:53 |
| psusi | apw, I have been asking for 6 months now if you are still actively working on bug #380138 that has been assigned to you for 18 months now. Are you actively working on it or should it no longer be assigned to you? Upstream has made changes that should finally allow us to drop this problematic patch. | 02:05 |
| ubottu | Launchpad bug 380138 in linux (Ubuntu) "Do NOT disable HPA by default -> leads to data loss" [Medium,In progress] https://launchpad.net/bugs/380138 | 02:05 |
| apw | psusi, no it has fallen off my radar | 02:06 |
| apw | psusi, what upstream changes have been made | 02:06 |
| psusi | apw, they have implemented a patch that detects whether any partitions would be truncated by the hpa and automatically unlocks the hpa if that is the case, otherwise, does not | 02:07 |
| apw | psusi, that sounds like it matches what we wanted indeed | 02:07 |
| apw | psusi, if you can point me to the change i can use that info | 02:08 |
| psusi | commit d8d9129ea28e2 | 02:08 |
| psusi | looks like it actually went in 2.6.35 | 02:09 |
| apw | psusi, indeed 35-rc2 | 02:09 |
| psusi | yep, it's in the maverick git tree | 02:09 |
| psusi | man I love git | 02:10 |
| apw | psusi, thanks for the heads up, sounds like we can drop this patch in natty and see how that pans out | 02:12 |
| psusi | woohoo, only took a few years ;) | 02:12 |
| psusi | now if we can just get the ext4 lazy_itable_init issue sorted in time for natty, 20 minute formats with the installer stuck at 5% will be a thing of the past | 02:13 |
| psusi | I hope ted packages the new e2fsprogs for debian soon so we can merge it | 02:14 |
| apw | psusi, we are expecting new e2fsprogs in debian shortly | 02:15 |
| apw | psusi, ok i am now 'active' on that bug ... will get something sorted out tommorrow ... need to get discussion started on it to ensure foundations are happy -- they were not last time we tried to change it | 02:16 |
| psusi | goody... I've been trying to get that feature turned on by default for a year... will be a boon to people with new tb class drives | 02:17 |
| apw | psusi, why are tb drives relevant ? | 02:18 |
| psusi | because they take AGES to format without lazy_itable_init ;) | 02:18 |
| psusi | and ubiquity just sits there at 5% complete and does not move the whole time.. very bad user experience | 02:18 |
| apw | ahh | 02:18 |
| psusi | we also probably want to have ubiquity mount with the option to inhibit the background initialization during installation so it doesn't slow down the install | 02:19 |
| apw | psusi, thanks for bringing that up | 02:20 |
| * apw goes back to bed | 02:21 | |
| psusi | o/ | 02:21 |
| ari-tczew | @pilot out | 07:05 |
| === 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 dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: | ||
| siretart | pasteeater: hi | 08:00 |
| pitti | cjwatson: python2.6 still is on today's alternate, despite python-apt being fixed; you mentioned that we need to "ask you for alternates", do you manually need to update something there? | 08:18 |
| pitti | cjwatson: I guess I'll do the 16 rebuilds then, and check if that helps | 08:19 |
| === axp2_ is now known as axp2 | ||
| === hunger_ is now known as hunger | ||
| === almaisan-away is now known as al-maisan | ||
| cjwatson | pitti: I was wrong about having to do something manually - that's only when things are dropped from priority required or important | 09:57 |
| cjwatson | pitti: python-apt still has the recommends in question, despite a changelog entry saying that it's been dropped | 09:58 |
| cjwatson | pitti: the rebuilds really should be unimportant for this - just fix python-apt properly :) | 09:59 |
| === masACC is now known as maswan | ||
| cjwatson | (well, they'd let you drop python2.7 from minimal again, yes) | 10:00 |
| mvo | cjwatson: eh, sounds like I need vacation | 10:00 |
| mvo | cjwatson: :( | 10:01 |
| mvo | cjwatson: I have a upload ready to fix a unreleated crash I will drop the recommends in that upload too (for real this time) | 10:01 |
| mvo | uploaded again | 10:04 |
| cjwatson | ta | 10:05 |
| pitti | ah, bummer | 10:13 |
| pitti | mvo: danke | 10:13 |
| pitti | mvo: control.in trap? | 10:14 |
| pitti | bbl | 10:15 |
| apw | mvo, is there a 'debrelease' command like debcommit for bzr based packages ? | 10:35 |
| mvo | apw: bzr-buildpackage | 10:36 |
| apw | mvo, our naming sucks! | 10:36 |
| apw | (but thanks) | 10:36 |
| mvo | apw: that is what I use, a lot of package have a .bzr-builddeb/defaults.conf that tell bzr-buildpackage what to do, if not you need to tell it to either "--merge" or "--native" | 10:36 |
| mvo | apw: otherwise it will not find its data :) | 10:36 |
| apw | mvo, oh that builds it, i meant is there a command to close the release, RELEASED -> natty, update the name and date on the -- line, commit result, tag result | 10:38 |
| mvo | apw: I use emacs for that, but others use dch | 10:39 |
| mvo | so dch -r | 10:39 |
| apw | mvo, ok so manual commit then ... thanks | 10:44 |
| mvo | apw: there is debcommit -r that will tag the branch, but iirc it does not change UNRELEASED to $distro | 10:52 |
| ari-tczew | @pilot in | 11:22 |
| === 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 dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew | ||
| ari-tczew | could any archive admin look on tor sync? bug 413657 | 11:27 |
| ubottu | Launchpad bug 413657 in tor (Ubuntu) "Please sync tor 0.2.1.26-4 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/413657 | 11:27 |
| ari-tczew | cdbs: you should know that there is a difference between FTBFS with missing linking and gcc 4.5 | 11:58 |
| ari-tczew | rawstudio/1.2-5ubuntu1 which you uploaded means fix ftbfs with missed links | 11:59 |
| cdbs | ari-tczew: If you read it clearly, I mentioned: Fixes FTBFS caused due to the new linking behavior in Ubuntu's GCC 4.5 | 11:59 |
| ari-tczew | cdbs: but it's not related to gcc 4.5 | 11:59 |
| cdbs | ari-tczew: it is | 11:59 |
| ari-tczew | cdbs: for example, it's ftbfs due to gcc 4.5: http://launchpadlibrarian.net/60956184/buildlog_ubuntu-natty-i386.u-boot_2010.12~rc2-1ubuntu1_FAILEDTOBUILD.txt.gz | 12:00 |
| cdbs | I know what you mean | 12:00 |
| cdbs | But the linker change is related to GCC 4.5 | 12:00 |
| ari-tczew | odd | 12:01 |
| cdbs | and I mentioned: FTBFS caused due to the *new* *linking* *behavior* in GCC 4.5 in Ubuntu | 12:01 |
| ari-tczew | cdbs: I guess that you mean due to new toolchain? | 12:01 |
| cdbs | of course | 12:01 |
| ari-tczew | cdbs: so this is not only gcc 4.5 | 12:02 |
| cdbs | new linking behavior -> passing of --no-copy-dt-whatever | 12:02 |
| ari-tczew | if I'm wrong, show me hard argumentation | 12:02 |
| cjwatson | it seems entirely unnecessary to nitpick this | 12:02 |
| cdbs | ari-tczew: Please understand the change before saying. GCC invokes LD | 12:02 |
| cdbs | and GCC is invoking LD with --no-copy-dt-entries | 12:02 |
| cdbs | err, its --no-copy-dt-needed-entries | 12:03 |
| cdbs | so its related to GCC | 12:03 |
| cjwatson | gcc-4.5 (4.5.0-1) experimental; urgency=low | 12:03 |
| cjwatson | * On linux targets always pass --no-add-needed to the linker. | 12:03 |
| cjwatson | (which is a synonym for --no-copy-dt-needed-entries) | 12:04 |
| cdbs | and --no-copy-dt-needed-entries is the same as --no-add-needed | 12:04 |
| cdbs | ari-tczew: I guess I am clear | 12:04 |
| cdbs | thanks cjwatson for that paste | 12:04 |
| ari-tczew | cdbs: ok it's also clear for me | 12:05 |
| Keybuk | cjwatson: sorry I'm late, it was hell getting into work this morning because of the snow | 12:09 |
| === axp2_ is now known as axp2 | ||
| === zyga is now known as zyga-coffee | ||
| kklimonda | ArneGoetje: wrt to tor - did debian maintainer agreed to take care of it in ubuntu, eventually did we get some motu to get his key into tor project? i can't check the bug but tor has been removed from ubuntu in the past. | 13:54 |
| Keybuk | 535event = event_new (NULL, name, (char **)env); | 14:06 |
| Keybuk | (gdb) p name | 14:06 |
| Keybuk | $1 = 0x671530 "dbus-activation" | 14:06 |
| Keybuk | (gdb) p env[0] | 14:06 |
| Keybuk | $2 = 0x6789e0 "SERVICE=my.test" | 14:06 |
| Keybuk | \o/ | 14:07 |
| mterry | @pilot in | 14:08 |
| === 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 dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew, mterry | ||
| * dholbach hugs mterry! | 14:09 | |
| mterry | dholbach, :) | 14:09 |
| Keybuk | ok, silly question time | 14:10 |
| Keybuk | if there's a debian package using 3.0 quilt | 14:10 |
| Keybuk | how do I add patches to it? | 14:10 |
| elmo | Keybuk: quilt new haha.patch ? | 14:18 |
| Keybuk | elmo: does haha.patch have to be in the working directory or under debian/patches ? | 14:18 |
| dholbach | edit-patch? | 14:19 |
| Laney | is that an existing patch? | 14:19 |
| Keybuk | Laney: they're existing patches, yes | 14:19 |
| elmo | Keybuk: oh, sorry, right, this mess | 14:19 |
| Laney | quilt import is what you want then | 14:19 |
| elmo | Keybuk: you may want to 'export QUILT_PATCHES=debian/patches' | 14:19 |
| Laney | edit-patch can do this too apparently | 14:20 |
| elmo | Keybuk: I used http://pkg-perl.alioth.debian.org/howto/quilt.html as a starting point when I was going through the same 'wtf' a while ago, FWIW | 14:20 |
| Keybuk | File series fully applied, ends at patch debian-changes-1.4.0-0ubuntu2 | 14:31 |
| Keybuk | Patch debian-changes-1.4.0-0ubuntu2 does not remove cleanly (refresh it or enforce with -f) | 14:31 |
| Keybuk | argh | 14:31 |
| Keybuk | what does that mean?! | 14:31 |
| Keybuk | Laney: so, neither of them did the right thing | 14:35 |
| Keybuk | quilt import didn't apply the patch to the working tree | 14:35 |
| Keybuk | edit-patch reverted all the debian patches in the working tree | 14:35 |
| Keybuk | I swear | 14:39 |
| Keybuk | quilt was invented because some people had got use to the pain of cdbs | 14:39 |
| Keybuk | and wanted more | 14:39 |
| ScottK | Keybuk: And like CDBS, eventually you'll get used to it. | 14:41 |
| ScottK | Eventually you'll criticize people for not enjoying the pain. | 14:41 |
| ScottK | ;-) | 14:42 |
| Keybuk | I suspect it's the combination of pain here | 14:44 |
| Keybuk | the package is actually using CDBS | 14:44 |
| Keybuk | and quilt | 14:44 |
| Keybuk | and all imported into bzr using james_w's abandoned stuff | 14:44 |
| mvo | bdrung: I commited a non-interactive add-patch version of edit-patch, would be nice if you could have a look | 14:44 |
| janimo | Keybuk: I think that combo is not supported by edit-patch (I fought with thunderbird packaging until I learned that) | 14:44 |
| bdrung | mvo: i will. thanks in advance | 14:45 |
| janimo | or actually cdbs tarball.mk + quilt is what caused problems | 14:45 |
| Keybuk | janimo: this looks like it's relying on dpkg to do the quilting | 14:45 |
| ScottK | cdbs tarball.mk plus anything is trouble (tarball in tarball using source format 1 is pure pain) | 14:46 |
| janimo | ScottK: luckily mozilla team say they want to move to quilt 3.0 so that will go away | 14:46 |
| mvo | bdrung: its only lightly tested and such, feedback welcome | 14:46 |
| ScottK | janimo: How are they going to support Hardy? | 14:46 |
| janimo | ScottK: I am not part of the mozilla team, so no idea :) | 14:47 |
| bdrung | mvo: you are welcome to provide testcases (online/offline). we are currently building a test infrastructure to catch regressions | 14:47 |
| janimo | Keybuk: I only had a problem with tbird packaging, and remembered I dislike quilt. But on every other package since then edit-patch did the right thing regardless of what the actual patch system | 14:48 |
| janimo | both quilt 3 and quilt cdbs worked fine | 14:49 |
| Keybuk | in this case, edit-patch seemed to remove all the patches from the tree | 14:49 |
| Keybuk | and tried to commit that | 14:49 |
| Keybuk | when dpkg-source 3 (quilt) in bzr is supposed to have all the patches *applied* at commit time | 14:50 |
| mvo | bdrung: indeed, that is currently missing | 14:50 |
| * janimo so far managed to not get into VCS backed patches (or if so edit-patch DTRT) | 14:50 | |
| janimo | Laney: I am trying to build ghc6 locally, and will let you know if I find the issue | 14:51 |
| === _LibertyZero is now known as LibertyZero | ||
| === tkamppeter_ is now known as tkamppeter | ||
| bdrung | mvo: add-patch is still interactive | 15:19 |
| bdrung | mvo: it launches an editor and let's me edit debian/changelog | 15:19 |
| bdrung | mvo: edit-patch should take bug number to close and should be able to set the target distribution | 15:21 |
| mvo | bdrung: hm, but it certainly needs some sort of description somewhere for the changelog. or are you happy with a generic "applied patch foo"? | 15:23 |
| bdrung | mvo: generic would be enough | 15:24 |
| ScottK | If I saw such a changelog entry in the sponsorship queue I would reject it. | 15:24 |
| bdrung | ScottK: sponsor-patch allows to edit it afterwards. | 15:25 |
| ScottK | OK. Seems odd to me. | 15:26 |
| ScottK | I've used cdbs-edit-patch and dpatch-edit-patch a lot and never once wanted them to write changelogs for me. | 15:26 |
| bdrung | one use case would be to grab patches from the reviewers list and test build them or upload to a ppa. | 15:26 |
| ScottK | Is this non-interactive mode a non-default option then? | 15:27 |
| cdbs | master? | 15:27 |
| bdrung | ScottK: should be | 15:27 |
| cdbs | BTW, I never understood what edit-patch does (I mean the script in u-d-t). Why use it when you can use cdbs-edit-patch and dpatch-edit-patch? | 15:27 |
| cdbs | sorry for writing that 'master'. Don't know how it came | 15:27 |
| ScottK | cdbs: What if the pacakge uses quilt? | 15:27 |
| ScottK | IIRC the point of edit-patch is not having to care what patch system is in use. | 15:27 |
| cdbs | ScottK: is edit-patch for quilt? | 15:28 |
| cdbs | okay | 15:28 |
| * ScottK would hope it includes support for it. | 15:28 | |
| bdrung | cdbs: edit-patch supports all patch systems | 15:28 |
| cdbs | I guess it writes changelog and stuff? and it has bzr support? | 15:28 |
| apw | doko_, you suggest conditionalising packaging on the release, is there an approved way to do that? | 15:35 |
| ScottK | wendar: I'm catching up on the backscroll and have a comment on your last ARB meeting: I would really prefer you don't choose to use ubuntu in the revision number for ARB apps. | 15:36 |
| doko_ | apw: well, I don't know. usually you have to rely on output of lsb_release, and have a rule to regenerate the control file (for the change of b-d's) | 15:38 |
| apw | doko_, ick, ok thanks | 15:38 |
| === zyga is now known as zyga-afk | ||
| === dholbach_ is now known as dholbach | ||
| wendar | ScottK: well, the apps are packaged for ubuntu, which is all that line means | 16:07 |
| ScottK | wendar: Except that extras is not part of Ubuntu. | 16:07 |
| wendar | ScottK: they'll still say "maverick" on that line too | 16:07 |
| wendar | ScottK: extras run on Ubuntu | 16:08 |
| ScottK | Why not just use $RELEASE. | 16:08 |
| wendar | ScottK: one of the developers did, but it's entirely non-standard | 16:08 |
| wendar | ScottK: we can certainly change the standard, but it needs to be a decision by a much larger group than the ARB | 16:09 |
| ScottK | wendar: There's a standard? | 16:09 |
| wendar | ScottK: so we'll stick with the current standard for now | 16:09 |
| * ScottK thought the current situtation was no defined standard? | 16:09 | |
| ScottK | wendar: Where is this standard? | 16:10 |
| wendar | ScottK: in the ubuntu packaging guide | 16:10 |
| ScottK | wendar: That's the standard for Ubuntu packages. These aren't Ubuntu packages. | 16:10 |
| ScottK | (and technically the standard is ubuntu-policy - the packaging guide just describes the policy) | 16:11 |
| wendar | ScottK: to be precise, they aren't "packages that make the core OS" they're "packages that run on the core OS" | 16:13 |
| wendar | ScottK: but they aren't Debian/Fedora/SuSE packages | 16:14 |
| ScottK | They equally aren't Ubuntu packages. | 16:14 |
| wendar | ScottK: we have main, universe, multiverse, and now extras, that has so far been taken as enough of a measure of how much support the Ubuntu community gives a package | 16:15 |
| wendar | ScottK: why add an additional linguistic marker? | 16:15 |
| directhex | precision is important | 16:15 |
| wendar | ScottK: the 0ubuntu1 means "this package was customized to run on the Ubuntu OS" | 16:16 |
| ScottK | wendar: Why make a choice the adds confusion? | 16:16 |
| ScottK | No. It means it's part of Ubuntu. | 16:16 |
| ScottK | You are proposing to change what that means. | 16:16 |
| wendar | ScottK: we have packages with out 0ubuntu1 that are part of Ubuntu | 16:17 |
| ScottK | That's true, but irrelevant. | 16:17 |
| ScottK | The fact that all XubuntuY packages are part of Ubuntu doesn't mean that all packages that are part of Ubuntu are XubuntuY | 16:17 |
| wendar | ScottK: I'm a linguist, and it's very important to me to get at the deep semantic and cultural meaning of a symbol or word | 16:18 |
| apw | marjo, remind me of the bug number | 16:19 |
| Chipzz | wendar: pretty ironic a linguist spells without in 2 words ;) | 16:19 |
| marjo | apw: https://bugs.launchpad.net/bugs/693093 | 16:19 |
| ubottu | Ubuntu bug 693093 in linux (Ubuntu) "[i945gme] 2.6.37-10.24: Black Screen on Boot" [Undecided,Confirmed] | 16:19 |
| wendar | Chipzz: I'm a linguist on a mission, and spending most of these few minutes scanning through documentation for signs of deeper semantic and cultural meaning of 0ubuntu1 | 16:20 |
| wendar | Chipzz: :) | 16:20 |
| apw | marjo, well that doesn't make sense as installing -10 doesn't change the older kernels and you are saying they have changed too | 16:21 |
| apw | marjo, that would imply it is a different component which has changed which is contributing | 16:21 |
| Chipzz | what deeper meaning do you expect? it's a version number, it has no semantic meaning | 16:21 |
| Chipzz | a version number purely exists to order packages in a timely fashion | 16:21 |
| Chipzz | ie to allow upgrades to happen correctly | 16:22 |
| marjo | apw: i tend to agree, but I don't know what else to try; all i know is that -9 used to work fine (gets to login and supported high resolution) | 16:22 |
| apw | marjo, and the fact that booting -9 does not implies it is something other than the kernel which is spacked | 16:22 |
| wendar | ScottK: can't find the page I'm looking for on why that naming convention was originally introduced (it might not exist anymore). I have a strong opinion to hold to existing standards until there's a compelling reason to change, but essentially, the ARB will do whatever the TB decides on it. | 16:24 |
| ScottK | wendar: I disagree that there is an existing standard for this. | 16:25 |
| apw | marjo, you may as well try updating to the -11 kernel and re-testing | 16:25 |
| Chipzz | wendar: to put it bluntly, your mission is bullshit. even if the proposal would have merit (which it doesn't (IMO)), the version number matters because computers order strings in a specific way, and 0ubuntu1 comes after 0, which is important because ubuntu packages should override debian packages | 16:25 |
| marjo | apw: will do | 16:25 |
| Chipzz | wendar: I think that alone is enough argument to put an end to this discussion | 16:26 |
| wendar | wendar: okay, then rephrase that to just "I have a strong opinion", but I do think this is something to be decided by the TB, and not by a small new group | 16:26 |
| wendar | (hmmm... talking to myself now?) | 16:26 |
| ScottK | wendar: I'm fine with the TB deciding. I think the current correct behavior is undefined. | 16:26 |
| Chipzz | wendar: there IS nothing to decide. your proposal would break ubuntu, period | 16:27 |
| ScottK | Chipzz: No. It wouldn't. | 16:27 |
| wendar | ScottK: we're deciding on a new standard that has the potential to last for 20 years or so | 16:27 |
| Chipzz | ScottK: as I understand it he wants to do away with ubuntu version numbers | 16:27 |
| ScottK | Chipzz: No. She doesn't. | 16:27 |
| wendar | Chipzz: it wouldn't break anything, I just want to use exactly what we're using now | 16:27 |
| ScottK | wendar: There is no "What we're using now". extras is new. | 16:28 |
| Chipzz | ScottK: then I misunderstood the discussion, my apologies | 16:29 |
| apw | marjo, we need you in #ubuntu-x | 16:29 |
| wendar | Chipzz: I want to use 2.0-0ubuntu1 and ScottK wants to use something else, maybe 2.0-0extras1 | 16:29 |
| ScottK | Chipzz: I don't think I'm the one you need to apologize to. | 16:29 |
| wendar | Chipzz: (we need to figure out what the something else would be, which is one of the reasons to take it to the TB) | 16:30 |
| ScottK | wendar: I'd even be happy with -0$RELEASE1 since these approvals are tied to a specific release. | 16:30 |
| Chipzz | wendar: ah ok, I understood the discussion as you wanting to eliminate 0ubuntu1 because it made no semantical sense | 16:31 |
| wendar | Chipzz: then your frustration is understandable :) I actually think it makes perfect sense, and want to keep using it. | 16:31 |
| ebroder | ScottK, wendar: Why not something like -0ubuntu0extras1? | 16:31 |
| wendar | ebroder: that has good potential | 16:32 |
| wendar | ebroder: or -0ubuntu0~extras1 like with PPAs | 16:32 |
| Chipzz | looks too complex to me | 16:32 |
| ebroder | That indicates to me that we would prefer to get these packages into the archive, at which point they'd supercede the packages in extras, which all seems more or less desirable | 16:32 |
| ebroder | wendar: I would probably use -0ubuntu1~extras1 if you went the tilde route | 16:33 |
| Chipzz | wendar: ~ has a specific meaning in versions, though I'm not sure if it's only at the start of a version or also anywhere else | 16:33 |
| ScottK | ebroder: It should not contain the string "ubuntu". | 16:34 |
| bdrung | ebroder: -0ubuntu0extras1 is more consistent | 16:34 |
| wendar | ebroder: and, it solves a problem too, if we treat it the same as PPAs, because it means the first universe release after the 'extras' release would always be considered "more recent" than the extras release | 16:34 |
| ScottK | Chipzz: It's anywhere. | 16:34 |
| wendar | ScottK: that basically comes down to what that instance of "ubuntu" means, a noun in isolation is tremendously ambiguious | 16:35 |
| === beuno is now known as beuno-lunch | ||
| apw | marjo, hey ... lots of dicsussion on #ubuntu-x | 16:36 |
| marjo | apw: having xchat problems | 16:36 |
| * apw wonders how you get to #ubuntu-meeting | 16:37 | |
| marjo | apw: auto-connect | 16:37 |
| apw | add ubuntu-x to that, and restart it perhaps? | 16:37 |
| marjo | apw: there now | 16:38 |
| marjo | apw: as marjo_ | 16:38 |
| Chipzz | ebroder: my 2c (FWIW), things like -0ubuntu0extras1 look too complex to me, and would likely cause confusion | 16:38 |
| bdrung | -0extras1 would be enough (less that -1 and -0ubuntu1) | 16:39 |
| ScottK | wendar: That's true and the core of my objection. I don't think it's possible to succesfully encode the distinction between in Ubuntu and on Ubuntu into the revision number, so I'd like for Ubuntu to be avoided entirely. | 16:39 |
| bdrung | s/that/than/ | 16:39 |
| Chipzz | sth you may want to avoid for MOTU's for example, as those ppl are often beginners, and they may struggle enough as is | 16:39 |
| wendar | Chipzz: that's good feedback | 16:40 |
| wendar | ScottK: I'll bundle the discussion up in an email for the TB. Doesn't necessarily need a meeting agenda item or a vote, but at least their thoughts. | 16:40 |
| Chipzz | wendar: sounds to me like you want input from the debian ppl too | 16:41 |
| ScottK | OK. | 16:41 |
| ebroder | wendar: Am I assuming correctly that it's desirable in the long-term for apps to move from extras into the archive? | 16:42 |
| Chipzz | sth which may be better is 0ubuntuextra1 (or 0ubuntu-extra1) | 16:43 |
| Chipzz | 0ubuntuextra1 would still be higher than 0ubuntu1 | 16:44 |
| Chipzz | but only 2 numbers instead of 3 | 16:44 |
| ebroder | Chipzz: I'm suggesting -0ubuntu0extras1 because I see it as being analogous to numbering packages -0ubuntu1 that are in Ubuntu but not yet in Debian | 16:45 |
| Chipzz | ebroder: yes, but then you have 3 numbers in one version string... | 16:46 |
| bdrung | dholbach: why does ubuntu-dev-tools depends on binutils? | 16:46 |
| dholbach | bdrung, I have no idea | 16:46 |
| dholbach | bdrung, ahhh - because of "nm"? | 16:47 |
| bdrung | dholbach: where is it used? | 16:47 |
| dholbach | check-symbols | 16:47 |
| ebroder | Chipzz: Sure, but it's not like you don't run into the same sorts of issues for SRUs, backports, etc. | 16:47 |
| Chipzz | ebroder: yes, but those happen only on an occasional basis, not on a regular one | 16:47 |
| Chipzz | ebroder: and I think ppl find those to be too complex in SRU's too | 16:48 |
| bdrung | dholbach: thanks | 16:48 |
| === zyga-afk is now known as zyga | ||
| ebroder | Chipzz: I don't think that makes them any less useful as indicators of the package's lineage | 16:50 |
| === deryck is now known as deryck[lunch] | ||
| apw | jhunt, what was the incantation to upstart to get more debug, was it --debug ? | 17:06 |
| === bdmurray_ is now known as bdmurray | ||
| Keybuk | apw: --debug --debug --moar-debug | 17:19 |
| Keybuk | (note, only the first one required) | 17:19 |
| === ximion1 is now known as ximion | ||
| === beuno-lunch is now known as beuno | ||
| apw | jhunt, what does "init: event_net: Pending started event" mean | 17:49 |
| apw | as the last bit of --debug | 17:50 |
| Keybuk | event_new you mean | 17:50 |
| apw | yes _new | 17:51 |
| apw | sorry going a bit mad | 17:51 |
| Keybuk | means that a job has started | 17:51 |
| Keybuk | though helpfully it doesn't say which, you need to look a line or two up for that | 17:51 |
| apw | Keybuk, so its not in the middle, its complete | 17:51 |
| Keybuk | right, that means the process has been exec'd and suff | 17:51 |
| apw | something very screwey goiing on in my worls | 17:52 |
| apw | world | 17:52 |
| === mtaylor is now known as mtaylor|afk | ||
| janimo | cjwatson: hello, can you please add me (jani @ ubuntu.com ) to the list of addresses notified when anything significant happens to arm image builds. thanks. | 17:56 |
| Keybuk | there are such addresses? | 17:57 |
| janimo | Keybuk: so I was told in #arm | 17:57 |
| ScottK | You can get ISO build failure notifications. | 17:58 |
| janimo | it may not be a mailing list, but apparently ogra & other arm devs are notified | 17:58 |
| Keybuk | neat | 18:09 |
| === deryck[lunch] is now known as deryck | ||
| kees | Keybuk, jhunt: so, should I upload the ubuntu1 debdiff for upstart to gain the apparmor helper, or should I wait for it to be included in the next release? (when is the next release?) | 18:13 |
| zyga | Keybuk, hi, dbus activation support is quite cool | 18:14 |
| Keybuk | kees: if you upload a debdiff it should be -2 | 18:14 |
| zyga | Keybuk, I posted a comment about the implementation but darn moderation will probably make it past xmas to deliver | 18:14 |
| kees | Keybuk: what's needed to get the change into the right vcs tree? | 18:14 |
| zyga | Keybuk, could you by any chance reuse the Exec= from .service file not to have to specify the same thing twice? | 18:15 |
| Keybuk | kees: uploading should do it | 18:15 |
| apw | Keybuk, any idea what was in the latest udev upload ? | 18:15 |
| Keybuk | zyga: I thought about adding it to the environment, but decided it would probably limit things | 18:15 |
| Keybuk | apw: none, pitti does those | 18:15 |
| zyga | Keybuk, not adding that to environment, just not having to specify it in a job file | 18:15 |
| ebroder | Keybuk: Do you still need to specify Exec and User in the .service file? Does D-Bus barf without those? | 18:16 |
| vanhoof | apw: some changes for new dell chassis support | 18:16 |
| Keybuk | zyga: then upstart would have to parse dbus service files, and then there's the whole mess of them being out-of-sync with each other, etc. | 18:16 |
| Keybuk | ebroder: no idea | 18:16 |
| zyga | Keybuk, yeah but you trade _development_ problem for _administration_ problem. They are going to get out of sync because you require two definitions. I argue to make just one definition in the .service file | 18:16 |
| Keybuk | zyga: if you want to support that though, go ahead | 18:17 |
| Keybuk | because it shouldn't be that hard to add an additional config parser to upstart | 18:17 |
| Keybuk | you could have upstart parse /usr/share/dbus-1/system-services, make Jobs out of them, etc. | 18:17 |
| Keybuk | I'll happily accept that patch | 18:17 |
| Keybuk | ^ | 18:17 |
| Keybuk | more then | 18:17 |
| zyga | Keybuk, do you have a separate non-copyright-assigned tree now or is that to the canonical treE? | 18:17 |
| Keybuk | zyga: I work for Canonical, so there is only the Canonical tree | 18:18 |
| zyga | Keybuk, that's another topic, so what's the point of having upstart file if we can (eventually) parse dbus service files? | 18:19 |
| Keybuk | zyga: well, there are lots of services that aren't dbus ;-) | 18:19 |
| zyga | Keybuk, is the upstartjob=y marker used by dbus _not_ to start that on activation and expect upstart to pick it up? | 18:20 |
| Keybuk | and in theory, dbus-daemon goes away | 18:20 |
| Keybuk | so the dbus service files will be the short-lived ones | 18:20 |
| zyga | Keybuk, mmm, interesting, what about handling of routed messages? | 18:20 |
| Keybuk | zyga: no, UpstartJob=y is used by D-Bus to replace the existing activation code with a D-Bus message to Upstart | 18:20 |
| Keybuk | zyga: multicast AF_UNIX | 18:20 |
| zyga | Keybuk, right, that's what I had on my mind, "delegate task to upstart" | 18:21 |
| zyga | Keybuk, so if we had the parser for .service files could we assume upstartjob=y always? | 18:21 |
| ebroder | zyga: There was a proof-of-concept a while back for an AF_DBUS :) | 18:21 |
| Keybuk | if the AF_UNIX multicast stuff gets accepted, then I'd expect to see | 18:21 |
| kees | Keybuk: FAIL: test_job_process | 18:21 |
| zyga | ebroder, yeah | 18:21 |
| kees | ^^ that test fails | 18:21 |
| Keybuk | - dbus services bind to AF_UNIX with their well known name | 18:21 |
| zyga | ebroder, but it did not remove the daemon | 18:21 |
| Keybuk | - dbus services listen on the multicast socket too | 18:21 |
| zyga | ebroder, it just made the actual talk more efficient | 18:21 |
| cjwatson | janimo: mail me, please, I'm not sitting somewhere where I can make that change right now | 18:21 |
| Keybuk | for activated services | 18:21 |
| Keybuk | - init binds to AF_UNIX with the well known name | 18:21 |
| Keybuk | - on message, activates the service and passes the socket | 18:22 |
| Keybuk | (ie. basically socket activation) | 18:22 |
| Keybuk | in both cases, you'd only have files in /etc/init | 18:22 |
| ebroder | zyga: I thought the proof-of-concept only used the dbus-daemon for the org.freedesktop.DBus stuff | 18:22 |
| zyga | ebroder, and for activation and for non-peer-to-peer messages | 18:22 |
| zyga | (I could be wrong on the last one) | 18:23 |
| Keybuk | kees: -v | 18:23 |
| ebroder | zyga: Oh, really? Well that's pointless :-P | 18:23 |
| Keybuk | ebroder: the new stuff is multicast AF_UNIX | 18:23 |
| cjwatson | wendar: here's the semantic of "ubuntu" in version numbers: it means "do not autosync this package from Debian" | 18:23 |
| cjwatson | wendar: that's its total meaning | 18:23 |
| zyga | Keybuk, that makes sense except for one thing - transition period - dbus has been around long enough so we have lots of .service files for dbus activation, do you think we should require to transition them to upstart jobs? | 18:23 |
| kees | Keybuk: I can't build upstart on natty, I get a failed testcase: | 18:24 |
| kees | test_job_process: tests/test_job_process.c:3740: test_handler: Assertion `(waitid (P_PID, pid, &info, 2 | 0x01000000)) == 0' failed. | 18:24 |
| kees | /bin/bash: line 5: 11151 Aborted (core dumped) ${dir}$tst | 18:24 |
| kees | FAIL: test_job_process | 18:24 |
| Keybuk | zyga: right, that's what I thought -- it seemed most sensible to do it as a transition thing | 18:24 |
| Keybuk | and to cover the overlap for when older kernels need dbus-daemon | 18:24 |
| Keybuk | while newer kernels don't | 18:24 |
| Keybuk | which is why I did it entirely as "have special handling in dbus-daemon" | 18:24 |
| Keybuk | rather than having any patch to upstart | 18:24 |
| zyga | ebroder, AF_DBUS patch did improve performance and removed the bottleneck that is the daemon for normal communication, I never used it just remember reading about it | 18:25 |
| Keybuk | kees: you're still not telling me which test case failed here ;-) | 18:25 |
| wendar | cjwatson: Makes sense. Seems like that would apply to the extras packages as much as any other. | 18:25 |
| zyga | Keybuk, I think it's still more sensible to keep .service files as is and let upstream be happy about not having to worry about upstart, upstart+1, sysinit or other stuff like systemd, | 18:25 |
| cjwatson | wendar: extras is never autosynced | 18:26 |
| zyga | Keybuk, it adds extra cruft but IMHO it's the best political decision | 18:26 |
| wendar | cjwatson: Though, with the /opt install, we'll always be modifying the packages. | 18:26 |
| Keybuk | zyga: I would have agreed, except Upstream already committed patches to add systemd support | 18:26 |
| cjwatson | autosyncing is just for the Ubuntu archive | 18:26 |
| Keybuk | so I followed the guide of those patches | 18:26 |
| zyga | Keybuk, we swap the implementation, not the interface for activation | 18:26 |
| kees | Keybuk: oh, "test_job_process" isn't it? | 18:26 |
| kees | Testing job_process_handler() | 18:26 |
| kees | ... | 18:26 |
| kees | ...with stopped main process but wrong signal | 18:26 |
| Keybuk | kees: no, test_job_process is about 1,000 test cases ;-) | 18:26 |
| zyga | Keybuk, upstream dbus? | 18:26 |
| wendar | cjwatson: Would you be comfortable with no modifier? | 18:26 |
| Keybuk | zyga: aye | 18:26 |
| Keybuk | kees: hmm, ok - can you check the core dump to see what assertion failed | 18:26 |
| wendar | cjwatson: i.e. 2.0-1? | 18:26 |
| zyga | Keybuk, I was referring to upstream projects shipping .service files, dbus is another topic where I agree with you | 18:26 |
| cjwatson | wendar: sure, it certainly wouldn't break anything and it seems simpler | 18:26 |
| Keybuk | kees: you may have found a kernel bug | 18:26 |
| Keybuk | zyga: well, the reason for doing this patch now | 18:27 |
| Keybuk | (we've never found it urgent until now) | 18:27 |
| cjwatson | we do that for some Ubuntu-specific packages, even | 18:27 |
| Keybuk | was to cover the base of upstream projects adding systemd support | 18:27 |
| Keybuk | and expecting you to activate it that way | 18:27 |
| kees | Keybuk: this assertion: | 18:27 |
| kees | test_job_process: tests/test_job_process.c:3740: test_handler: Assertion `(waitid (P_PID, pid, &info, 2 | 0x01000000)) == 0' failed. | 18:27 |
| Keybuk | this gives us an upstart answer | 18:27 |
| wendar | cjwatson: okay, cool, thanks | 18:27 |
| Keybuk | kees: yeah, looking at the code, you found a kernel bug | 18:27 |
| zyga | Keybuk, right, that's a sensible first step | 18:27 |
| apw | something seems to be wrong with something in our initramfs in natty | 18:27 |
| kees | Keybuk: \o/ | 18:27 |
| zyga | Keybuk, I'm more probing you on the follow-up you'd like to see | 18:27 |
| apw | i have a bad -11 kernel, i regenerated my -10 initramfs and it is also sick now | 18:28 |
| Keybuk | kees: because that assertion is asserting that a child paused by SIGTSTP causes wait() to report WSTOPPED | 18:28 |
| Keybuk | zyga: I don't expect to see a mass conversion of system services from dbus to upstart | 18:28 |
| Keybuk | in fact, I don't really expect to see any | 18:28 |
| wendar | cjwatson: will drop a note to the TB for "chance to comment", but will go with the simple option unless anything else come up | 18:29 |
| zyga | Keybuk, I was asking about the next step for upstart implementation | 18:29 |
| Keybuk | but next time someone says "we have to use systemd because d-bus uses it for service activation" the answer is "no, upstart can do d-bus service activation too" | 18:29 |
| zyga | Keybuk, if we can make all dbus services activated by upstart implicitly | 18:29 |
| Keybuk | zyga: i'm not sure that needs an upstart patch | 18:29 |
| zyga | hmm | 18:29 |
| Keybuk | one could patch d-bus so that rather than read in .service files, it just unconditionally emits the dbus-activation event | 18:29 |
| zyga | btw | 18:29 |
| Keybuk | I considered that | 18:29 |
| zyga | why didn't you just patch dbus | 18:30 |
| Keybuk | I did just patch dbus | 18:30 |
| zyga | Keybuk, to actually send you job details upon activation | 18:30 |
| zyga | Keybuk, no parsin needed, | 18:30 |
| Keybuk | zyga: that's what I said earlier | 18:30 |
| zyga | Keybuk, you already have an API for that | 18:30 |
| zyga | Keybuk, hmm? I must have missed that somehow | 18:30 |
| ebroder | Keybuk: Does the systemd integration basically work the same way as upstart? Setting the flag -> D-Bus doesn't start the service itself? | 18:30 |
| Keybuk | <Keybuk> zyga: I thought about adding it to the environment, but decided it would probably limit things | 18:30 |
| Keybuk | ebroder: right | 18:30 |
| apw | cjwatson, who other than you (ie someone who is arround) would be a good person to help diagnose an early boot failure, likely something in initramfs | 18:30 |
| ebroder | Ugh. That seems like a terrible design | 18:30 |
| zyga | Keybuk, but why not activate _all_ jobs like that? No UpstartYob=y no extra upstart file | 18:31 |
| Keybuk | ebroder: setting the flag means d-bus emits a signal that systemd listens to | 18:31 |
| zyga | just pure dbus service that always gets activated by patched dbus sending message (as you currently do) to upstart | 18:31 |
| Keybuk | likewise setting the upstart flag means d-bus makes a method call to upstart | 18:31 |
| Keybuk | zyga: because it changes the behaviour of d-bus | 18:31 |
| zyga | Keybuk, in what way? | 18:31 |
| ebroder | Keybuk: Right. But since there are more init daemons than D-Bus daemons, I can't see why D-Bus needs to buy into the init daemons instead of the other way around | 18:31 |
| Keybuk | zyga: right now, if you send a method call to an un-named service | 18:31 |
| Keybuk | for which there isn't a .service | 18:31 |
| Keybuk | the method call returns an error immediately | 18:31 |
| zyga | right | 18:32 |
| Keybuk | to have d-bus unconditionally activate would mean all such methods would timeout instead | 18:32 |
| Keybuk | (activate via upstart) | 18:32 |
| tseliot | cjwatson: are you around? | 18:32 |
| zyga | Keybuk, hmm why? | 18:32 |
| Keybuk | ebroder: because the init daemons are "higher up" the stack | 18:32 |
| zyga | Keybuk, dbus would not activate that blindly | 18:32 |
| cjwatson | wendar: ok, sounds good | 18:32 |
| zyga | Keybuk, just check if the service exists, (it already does that) | 18:32 |
| Keybuk | zyga: you just asked why dbus doesn't activate blindly | 18:32 |
| Keybuk | right | 18:32 |
| Keybuk | if the service exists, dbus will activate it | 18:32 |
| zyga | Keybuk, and pass the sole activation step (with all the details) to upstart | 18:32 |
| Keybuk | because then all existing services would immediately break | 18:33 |
| Keybuk | because there wouldn't be upstart jobs for them | 18:33 |
| tseliot | cjwatson: is it ok if a blacklist in /usr/share/grub-gfxpayload-lists/blacklist/ is a symlink to the actual blacklist file? | 18:33 |
| zyga | Keybuk, no - I asked (earlier) why don't we just forward all activation requests to upstart. Why do we need the upstartjob=y flag? | 18:33 |
| Keybuk | zyga: right | 18:33 |
| Keybuk | because then you'd have to write upstart job files for them *quickly* | 18:34 |
| Keybuk | if d-bus ignored the .service file | 18:34 |
| Keybuk | and there wasn't an upstart job for it yet | 18:34 |
| cjwatson | apw: try Surbhi perhaps | 18:34 |
| Keybuk | it would break | 18:34 |
| Keybuk | that's what the flag is for | 18:34 |
| cjwatson | tseliot: not in front of the code right now but IIRC it just cats them together | 18:34 |
| Keybuk | the flag means "this one has been converted" | 18:34 |
| Keybuk | the contents of the .service file are there for backwards compatibility | 18:34 |
| cjwatson | tseliot: check the implementation but it should be ok | 18:34 |
| zyga | Keybuk, why would you have to write upstart jobs? I don't want to patch dbus to ignore it's own service files. I just want it to send the details about the service to upstart when it decides that given service should be activated | 18:34 |
| zyga | Keybuk, after parsing the actual service file and getting stuff like Exec out of it | 18:35 |
| Keybuk | zyga: how would that help? | 18:35 |
| zyga | Keybuk, less administration | 18:35 |
| zyga | Keybuk, one file to maintian | 18:35 |
| Keybuk | then you wouldn't be able to customise any of the jobs | 18:35 |
| Keybuk | less administration is not necessarily a good thing | 18:35 |
| zyga | Keybuk, zero files to patch | 18:35 |
| zyga | Keybuk, yes but that's another step | 18:35 |
| Keybuk | no, there's no gain to that | 18:35 |
| Keybuk | just having d-bus get upstart to do the job it's already doing is zero benefit | 18:35 |
| zyga | Keybuk, getting jobs activated via upstart per se would just be a transparent improvement of the implementation | 18:35 |
| Keybuk | no, it would be a transparent *movement* of the implementation | 18:36 |
| zyga | Keybuk, you gain uniformity | 18:36 |
| Keybuk | no you don't | 18:36 |
| Keybuk | because the d-bus activation wouldn't be uniform with the rest of the upstart systme | 18:36 |
| zyga | Keybuk, you already added the implementation, right? there are two ways to activate dbus services now, via upstart and via dbus | 18:36 |
| Keybuk | all dbus activation would be done by a single .conf file | 18:36 |
| elif | Hey guys I'm a bit confused since I'm trying to use preseed, I read the ubuntu-installer is ubiquity, but I donwloaded the ubuntu 10.10 server, x6-64 and I don't see the ubiquity there, instead just the debian installer, so automatic-ubiquity kernel parameter does nothing... is this right (no ubiquity as installer) ? | 18:36 |
| tseliot | cjwatson: yes, it's correct. I've just found what you put on pastebin: http://paste.ubuntu.com/544450/ | 18:36 |
| Keybuk | zyga: three, actually | 18:36 |
| Keybuk | but yes | 18:36 |
| Keybuk | the existing implementation had two days | 18:36 |
| Keybuk | I added a third | 18:36 |
| Keybuk | two ways | 18:37 |
| cjwatson | elif: the desktop (graphical) installer is ubiquity. the text installer is a modified version of debian-installer. | 18:37 |
| zyga | Keybuk, so why not unify that to one (via upstart) on ubuntu? Am I missing something? | 18:37 |
| zyga | (apart from the actual extra work required) | 18:37 |
| Keybuk | on receiving a message for a destination not connected to the bus, the D-Bus Daemon performs an Activation | 18:37 |
| Keybuk | the process for that, in the upstream code: | 18:37 |
| Keybuk | - look-up and parse a .service file | 18:37 |
| zyga | when/if someone wants to use upstart interface they just stop shipping .service file for dbus and ship an upstart job instead | 18:38 |
| Keybuk | - if the service has SystemdService=..., invoke systemd to do it | 18:38 |
| zyga | uh :-) | 18:38 |
| zyga | right, third | 18:38 |
| Keybuk | - otherwise, do it by hand using Exec | 18:38 |
| Keybuk | I added an intermediate step | 18:38 |
| cjwatson | elif: just use file= or url= as appropriate to point to the preseed file - see the installation-guide | 18:38 |
| Keybuk | - if the service has UpstartJob=y, invoke upstart to do it | 18:38 |
| Keybuk | so basically I implemented it uniformly with the existing D-Bus upstream code | 18:38 |
| Keybuk | now | 18:38 |
| Keybuk | I could have done it differently | 18:38 |
| Keybuk | I could have said | 18:39 |
| Keybuk | - if the bus is being activated via Upstart | 18:39 |
| Keybuk | - punt ALL activation requests (whether .service or no) to Upstart | 18:39 |
| zyga | right | 18:39 |
| Keybuk | this would have had the following effect: | 18:39 |
| Keybuk | - broken all existing services | 18:39 |
| * zyga remembers your post about not replacing dbus years ago ;-) | 18:39 | |
| Keybuk | - changed the behaviour of d-bus for *NON* activated services | 18:39 |
| Keybuk | - made a big patch upstream would have cried about | 18:39 |
| Keybuk | so that's bad | 18:39 |
| Keybuk | even though it might be ultimately better | 18:40 |
| zyga | hmm, this is the part I dont understand | 18:40 |
| zyga | (I'm not dbus expert so please bear with me if you can) | 18:40 |
| zyga | how is the method you implemented now (delegation of the activation process to upstart for selected jobs) not breaking them the way you described above? | 18:40 |
| kees | Keybuk: bug 693510 filed | 18:40 |
| ubottu | Launchpad bug 693510 in linux (Ubuntu) "child paused by SIGTSTP fails to cause wait() to report WSTOPPED" [Undecided,New] https://launchpad.net/bugs/693510 | 18:40 |
| Keybuk | zyga: because it's done via a flag | 18:41 |
| zyga | imagine if _each_ job had useupstart=y and an appropriate (generated) upstart job file | 18:41 |
| elif | cjwatson, I'm writing preseed.cfg and packing it with the initrd, it works, but in mirror selecting part it always keep me asking to choose a mirror, I check what question name it was, I found it was "debian-installer/choose-mirror/title", of type Text, but no matter what I do it keeps asking me this question | 18:41 |
| Keybuk | so it only changes the behaviour of an ACTIVATED service | 18:41 |
| zyga | what would change then? | 18:41 |
| Keybuk | and only an activated service THAT HAS BEEN MODIFIED | 18:41 |
| zyga | hmm? | 18:41 |
| * zyga should reread your message perhaps | 18:41 | |
| Keybuk | upstart doesn't autogenerate job files | 18:41 |
| Keybuk | so | 18:41 |
| Keybuk | right | 18:41 |
| Keybuk | there's a third option | 18:41 |
| Keybuk | - if no .service is present, fail | 18:41 |
| cjwatson | elif: that's certainly not the question name being asked | 18:41 |
| Keybuk | - if a .service is present, parse it | 18:41 |
| zyga | (I know it does not - I was putting a theory on what would change in such scenario) | 18:41 |
| Keybuk | - send all information over to upstart so upstart can run it | 18:41 |
| Keybuk | but honestly, that buys us nothing | 18:42 |
| elif | cjwatson, it display the list with the answer provided in "mirror/http/hostname" | 18:42 |
| Keybuk | we wouldn't be able to customise each job indepedantly | 18:42 |
| zyga | Keybuk, what you just described is what I was generally arguing for the whole time | 18:42 |
| Keybuk | we would still need to create a file in one place to have it run by a system configured in another | 18:42 |
| Keybuk | right, and that's idioitic | 18:42 |
| Keybuk | it has zero benefit | 18:42 |
| Keybuk | and just complicates matters further | 18:42 |
| zyga | no wait | 18:42 |
| Keybuk | consider | 18:42 |
| zyga | there's something not right here: why would you need to create another file? | 18:42 |
| Keybuk | listen | 18:42 |
| elif | cjwatson, do you have a sugestion of the question name ? | 18:42 |
| cjwatson | elif: if you're setting hostname and directory, did you set (iirc) 'd-i mirror/http/country string manual'? | 18:43 |
| Keybuk | so, we want to create a new service to be system-bus activated | 18:43 |
| zyga | if you send _all_ the description required by upstart to start the new job why would you need to add a upstart job file (unless I mistake something) | 18:43 |
| Keybuk | we would *have* to create a file in /usr/share/dbus-1/system-services | 18:43 |
| zyga | right | 18:43 |
| Keybuk | to configure Upstart | 18:43 |
| apw | anyone know if pitti is about? | 18:43 |
| Keybuk | that's confusing in of itself | 18:43 |
| Keybuk | that file is parsed by D-Bus | 18:43 |
| zyga | right | 18:43 |
| apw | Keybuk, cjwatson, i believe that the current udev in the archive is bad | 18:43 |
| cjwatson | elif: I'm ircing from a phone right now, I can't check all the facts. if you're stuck feel free to mail your preseed.cfg and your installer syslog to cjwatson@ubuntu.com and I'll look when it's more convenient | 18:43 |
| Keybuk | so it can have *NONE* of the features of Upstart that D-Bus doesn't know about | 18:43 |
| zyga | right | 18:44 |
| Keybuk | so you gain zero benefit from Upstart | 18:44 |
| zyga | right | 18:44 |
| elif | cjwatson, oh thks. | 18:44 |
| zyga | I agree with everything you said | 18:44 |
| Keybuk | so, all you've done there is move the supervising from d-bus to upstart | 18:44 |
| Keybuk | for a benefit of zero | 18:44 |
| Keybuk | at a cost of increased complexity | 18:44 |
| zyga | that depends on the viewpoint but I agree | 18:44 |
| zyga | what you did not do is also important | 18:44 |
| zyga | you made the activation uniform, there is no heisenbug that sometimes kicks in when service gets activated by upstart | 18:45 |
| zyga | you made this process transparent to anyone who now today ships a .service file for upstart | 18:45 |
| zyga | and provided a clear upgrade path to upstart features | 18:45 |
| zyga | now | 18:45 |
| zyga | compare that to current situation | 18:45 |
| Keybuk | apw: oh, wow, someone uploaded 165 - I took one look at those release notes and backed away | 18:45 |
| zyga | if you want to use upstart then shipping service file is mostly useless | 18:45 |
| Keybuk | zyga: correct | 18:45 |
| zyga | except for the flag that you need to add | 18:45 |
| Keybuk | zyga: except services are shipped by upstreams | 18:46 |
| zyga | and the (probably unused) Exec line | 18:46 |
| Keybuk | so this allows an upstream to ship a service file for sysvinit distros | 18:46 |
| Keybuk | a systemd unit for systemd distros | 18:46 |
| ari-tczew | cjwatson: are you not afraid to write full mail address here? (spam case) | 18:46 |
| zyga | and on top of that you need to create an upstart job file for the actual gory details of what you want to do | 18:46 |
| Keybuk | and an upstart job for upstart distros | 18:46 |
| cjwatson | ari-tczew: no | 18:46 |
| zyga | Keybuk, yeah and IMHO upstreams will hate that | 18:46 |
| apw | ari-tczew, his email is so well known he cannot make it any more on spam lists than it already is | 18:46 |
| zyga | Keybuk, they were happy with .service for dbus | 18:46 |
| Keybuk | zyga: of course they will | 18:46 |
| Keybuk | like I said, I expect no services to be migrated ;-) | 18:47 |
| zyga | Keybuk, few will want to get the extra features that upstart and systemd offer | 18:47 |
| Keybuk | not until dbus-daemon goes away, anyway | 18:47 |
| zyga | Keybuk, actually having _not_to_ do this for upstart would be an improvement over systemd | 18:47 |
| zyga | Keybuk, you essentially invent a new interface for no gain | 18:47 |
| Keybuk | zyga: *except* these patches have to be accepted by D-Bus upstream | 18:47 |
| Keybuk | we can't go around cowboying the universe | 18:47 |
| zyga | Keybuk, hmm | 18:47 |
| Keybuk | (yeehaw!) | 18:47 |
| Keybuk | so look at this instead from a "next year" POV | 18:48 |
| Keybuk | let's say Collabora's patches to add multicast AF_UNIX are accepted into the kernel | 18:48 |
| Keybuk | D-Bus communication can now be implemented entirely without an intermediary daemon | 18:48 |
| Keybuk | except for Activation | 18:48 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| Keybuk | but this is only true for newer kernels | 18:48 |
| Keybuk | so you need to have a dbus-daemon around for older kernels | 18:49 |
| zyga | Keybuk, so next year everyone will stop shipping .service files for older distros? Either upstart job or system unit? | 18:49 |
| ebroder | Keybuk: Isn't there a problem that Upstart supports doing more things in its conf file than D-Bus does? Same with systemd? So either an application only writes in its Upstart conf file what it can do in pure D-Bus (in which case why not just get the configuration from the normal D-Bus location), or it drops support for pure D-Bus without systemd or Upstart (which would be lame on the app's part) | 18:49 |
| Keybuk | zyga: you got it ;-) | 18:49 |
| zyga | Keybuk, that's what I don't like | 18:49 |
| Keybuk | ebroder: initially, but only for an LTS cycle or so | 18:49 |
| zyga | Keybuk, I like the old interface, there's nothing wrong with it | 18:49 |
| Keybuk | zyga: it's not very flexible | 18:49 |
| zyga | Keybuk, I second ebroder's comment on this | 18:49 |
| zyga | Keybuk, true | 18:49 |
| zyga | Keybuk, so you have two upgrade paths: systemd and upstart | 18:50 |
| Keybuk | yes | 18:50 |
| zyga | Keybuk, but if it's okay for you you don't have to worry about the next ubuntu breaking the world for no good reason | 18:50 |
| kees | Keybuk: hrm, this should be the minimal test case, right? run alone, it works fine. http://paste.ubuntu.com/546681/ | 18:50 |
| Keybuk | zyga: what's it got to do with breaking the world? | 18:50 |
| Keybuk | kees: no idea | 18:50 |
| zyga | Keybuk, if you don't change your code (to support upstart/systemd) how will your dbus .service get activated without the deaemon? | 18:50 |
| Keybuk | zyga: it won't | 18:51 |
| zyga | broken! | 18:51 |
| zyga | :-) | 18:51 |
| zyga | see what I mean? | 18:51 |
| Keybuk | that's just the day-to-day business of linux | 18:51 |
| zyga | why cannot we just keep that support | 18:51 |
| Keybuk | if you still have an agent in /etc/hotplug - it won't work now :p | 18:51 |
| ebroder | Keybuk: I think my issue is mostly that D-Bus is currently init-daemon agnostic, and it seems lame to switch to a model that is no longer agnostic of the init daeomn, especially when there's more than one popular daemon right now | 18:51 |
| zyga | Keybuk, I hope you don't believe that ;-) | 18:51 |
| Keybuk | zyga: I didn't say we couldn't - in fact, I believe I asked you to write it ;-) | 18:51 |
| zyga | Keybuk, there is _nothing_ wrong with those files | 18:51 |
| zyga | Keybuk, great :-) | 18:51 |
| Keybuk | ebroder: but that switch has already happened | 18:51 |
| Keybuk | ebroder: we're just catching up | 18:51 |
| zyga | Keybuk, so at least we agree that it's not an issue to support that | 18:51 |
| ebroder | That doesn't make it any less of a terrible design decision | 18:52 |
| Keybuk | zyga: I have zero problem with upstart parsing the existing dbus service files | 18:52 |
| Keybuk | and generating jobs from it | 18:52 |
| zyga | Keybuk, so that the world has a common denominator to target if they are fine with the subset of features they might otherwise get | 18:52 |
| zyga | Keybuk, what about dbus parsing them and just sending the details over the wire? this way there is almost no patch for upstart and rather smallish patch for dbus (I might try to do that over xmas) | 18:52 |
| Keybuk | zyga: that's a lot of effort to add to d-bus | 18:53 |
| Keybuk | which is going away | 18:53 |
| zyga | Keybuk, hmm | 18:53 |
| Keybuk | and then, when the daemon vanishes, you'd need to do it all again | 18:53 |
| Keybuk | if upstart were patched to parse them in the first place | 18:53 |
| zyga | Keybuk, do you think that everyone will actually drop the daemon? | 18:53 |
| Keybuk | then the effort is only done once | 18:53 |
| Keybuk | and lasts forever | 18:53 |
| Keybuk | zyga: that's certainly what everyone wants to do | 18:53 |
| Keybuk | it's Slooooowwww | 18:53 |
| zyga | Keybuk, if that's really going to happen then you are right, parsing the stuff in upstart is better | 18:53 |
| * janimo wonders what is the difference between armel and other builds servers, as debian/rules only fails on armel due to an error in mv | 18:54 | |
| zyga | janimo, armel is never virtual | 18:54 |
| zyga | janimo, and has some security around that so that random build should not take over the system | 18:54 |
| zyga | janimo, what was the move that failed? | 18:55 |
| cjwatson | zyga: distro buildds in general aren't virtual | 18:55 |
| janimo | zyga: in the ghc6 build, moving some doc files as the install step of the build | 18:55 |
| zyga | (except for qemu of course but I don't know if we have that in our builds) | 18:55 |
| zyga | cjwatson, are x86 packages not build by virtual machnies? | 18:55 |
| cjwatson | zyga: only ppas | 18:55 |
| janimo | zyga: I was expecitng all makesfiles to fail when a mv fails but only armel did | 18:55 |
| zyga | cjwatson, hmm | 18:55 |
| zyga | cjwatson, ah, so we trust our packages more to let them run on hardware, right? | 18:56 |
| cjwatson | janimo: look up in the log to see if something failed earlier (e.g. it failed to build the docs) and buggily failed to notice | 18:56 |
| janimo | and I see quite a few mv: cannot stat file .... causing FTB in debian and ubuntu during the years | 18:56 |
| cjwatson | zyga: yes | 18:56 |
| zyga | Keybuk, thanks for the clarifications | 18:56 |
| zyga | Keybuk, I'll have a look at this over xmas | 18:56 |
| janimo | cjwatson: will check. The same thing built locally on armel | 18:56 |
| cjwatson | I certainly very much doubt that mv is fundamentally different on armel! | 18:57 |
| Keybuk | zyga: the patch isn't so much an "ideal world" more of a "here's our reaction to the systemd patch" | 18:57 |
| zyga | Keybuk, yeah, it shows | 18:57 |
| janimo | cjwatson: one file that it expects to mv is missing but that is the case for x86 as well | 18:57 |
| === dendrobates is now known as dendro-afk | ||
| Laney | janimo: thanks, I hope to get some time soon | 19:06 |
| janimo | Laney: strangely it buildt locally | 19:06 |
| Laney | I will upload 6.12.3 soon though, so we can see if it's fixed by that | 19:06 |
| janimo | Laney: ok. the only packaging change I can think of is to ignore mv errors in the haddock section | 19:07 |
| janimo | just to rule out that this trips over armel | 19:07 |
| === dendro-afk is now known as dendrobates | ||
| Laney | yes | 19:07 |
| === al-maisan is now known as almaisan-away | ||
| Laney | but it's a concerning failure nonetheless | 19:08 |
| apw | Keybuk, do you know if there is any debug in udev at all ? | 19:08 |
| janimo | Laney: are the arm and pthread fixes in 6.12.3 upstream or you will carry them in packaging | 19:08 |
| Laney | I got it from a nug | 19:08 |
| Laney | a bug* | 19:09 |
| janimo | Laney: only one package (base 3 ) does not provide *.haddock files and that is the error. Not sure if it is supposed to have those files though | 19:09 |
| Laney | it never failed like that before | 19:09 |
| ion | keybuk: Looking at http://launchpadlibrarian.net/61083245/dbus_1.4.1-0ubuntu1_1.4.1-0ubuntu2.diff.gz it seems an extraneous whitespace change has sneaked into a patch, search for process_config_every_time. | 19:10 |
| Keybuk | *gasp* | 19:12 |
| Keybuk | not extraneous whitespace! | 19:12 |
| mterry | @pilot out | 19:12 |
| === 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 dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew | ||
| Keybuk | I think I was probably un-tabbing things | 19:12 |
| Keybuk | and turning them back into spaces | 19:12 |
| Keybuk | apw: only if you recompile it | 19:12 |
| apw | Keybuk, and i'd be right in thinking there is no sensible way to go back a version in the archive | 19:13 |
| cjwatson | apw: correct, particularly not back an upstream version. better to fix it ... | 19:24 |
| bdmurray | mdz: I seem to recall you modifying apport or dpkg to not report short read in buffer copy bugs is that right? Oh, it was only for english ones yes? | 19:25 |
| apw | cjwatson, /me has no idea as to the cause the symptoms for me are an unbootable kernel, i think sarvatt is affected too, he may be able to login to his after | 19:25 |
| === yofel_ is now known as yofel | ||
| === sk0rv is now known as skorv | ||
| mdz | bdmurray, yes | 20:15 |
| mdz | bdmurray, apt actually | 20:15 |
| === juliank0 is now known as juliank | ||
| bdmurray | mdz: and it was english only? | 20:21 |
| bdmurray | mdz: found it - thanks | 20:22 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === diwic is now known as diwic_afk | ||
| jdstrand | hallyn, apw: I am seeing some weird, but major kvm regressions with the last two natty kernels | 21:12 |
| jdstrand | hallyn, apw: my hunch is something with ksm, but I don't know. the symptoms are if I run 2 or more vms at once, the vms are extremely flaky, with random segfaults all over | 21:13 |
| jdstrand | hallyn, apw: hold on. I'll report back later | 21:14 |
| jdstrand | hallyn, apw: there is a bug, but I'm still investigating. it might be with the hardware. nm for now | 21:37 |
| hallyn | jdstrand: kthx | 21:48 |
| === JFo is now known as JFo-vacation | ||
| === Quintasan_ is now known as Quintasan | ||
| === Auv5 is now known as JackMc | ||
| === Sarvatt_ is now known as Sarvatt | ||
| ebroder | RAOF: We talked a month or two ago about stopping the X server from changing video modes when it starts to give gnome-settings-daemon a chance to pick the best mode. Have you had a chance to look into that yet? | 23:16 |
| ebroder | (And is there anything I, as someone who knows very very little about the X server, can do to help?) | 23:17 |
| RAOF | ebroder: I haven't yet, no. I got pulled into a whirlpool of dri2. | 23:18 |
| RAOF | There's probably not much to do outside of adding a driver hook to startup to say “hey, there's a nice mode already set, just let me use that”. | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!