| broder | hallyn: ping? around? | 00:06 |
|---|---|---|
| broder | actually, unping | 00:08 |
| broder | we need a better way to keep track of contributors than the changed-by line. it sucks that i can only give one person credit for a change in a way that we can easily collate automatically | 00:09 |
| broder | anybody with some upstart-fu around? i'm trying to figure out the semantics of calling "stop;" from within an upstart script | 00:12 |
| User_007 | hello, i made some changes in a package source and i want to upload it to my ppa, how can i generate a .changes so i can upload it? | 00:22 |
| broder | User_007: you can run "bzr bd -S" if you're using a bzr branch, or "debuild -S" otherwise | 00:23 |
| User_007 | broder, i only have the modified code, how do i create a .changes? | 00:26 |
| broder | User_007: do you mean that you only have a diff, as opposed to a full package? | 00:27 |
| crossfader | hi | 00:35 |
| crossfader | ich weiss ja nicht, ob grad jemand da ist, der sich damit auskennt... | 00:35 |
| broder | !de | crossfader | 00:36 |
| ubottu | crossfader: In den meisten Ubuntu-Kanälen wird nur Englisch gesprochen. Für deutschsprachige Hilfe besuche bitte #ubuntu-de, #kubuntu-de, #edubuntu-de oder #ubuntu-at. Einfach "/join #ubuntu-de" eingeben. Danke für Dein Verständnis! | 00:36 |
| crossfader | ich will meinem kernel klar machen, dass er das root-fs über nfs zu ist | 00:36 |
| crossfader | oops | 00:36 |
| crossfader | sorry | 00:36 |
| crossfader | joined the wrong channel | 00:36 |
| broder | no problem :) | 00:36 |
| crossfader | anyway, meybe you can help me | 00:36 |
| broder | just wasn't sure whether you spoke english, and the bot's german is better than mine :-P | 00:36 |
| crossfader | i try to boot my kernel into an nfs root-filesystem | 00:37 |
| DawnLight | how come user processes are children of init directly? i would expect them to be children of gnome-session of unity or whatever | 00:37 |
| User_007 | broder, sorry i only have the modified source, i mean, i downloaded the .orig.tar.bz extracted it and made my changes. Can you point me a step-by-step? | 00:37 |
| broder | User_007: have you looked at http://developer.ubuntu.com/packaging/html/fixing-a-bug.html ? it has a good walkthrough for how to get the source and make a change to it | 00:38 |
| broder | you need more than just the orig.tar.bz | 00:38 |
| User_007 | thanks, i will read it. | 00:38 |
| broder | DawnLight: there are a lot of ways that user processes can be started, and lots of reasons that they might end up parented to init. any process whose parents dies, for instance, is automatically reparented | 00:39 |
| DawnLight | broder, thanks | 00:39 |
| DawnLight | i want to make a modification in ubuntu that whenever a user's locale is one of the several RTL locales and he tries to log into a unity session, he falls back to unity-2d, instead. where would i insert the code to that? | 00:42 |
| DawnLight | in unity? in gnome-session? | 00:42 |
| crossfader | i use the linux 2.6.24-30-generic kernel... as provided most actual kernel in Hardy | 00:42 |
| crossfader | can i use the kernel-boot-parameter root=/dev/nfs with that kernel? does somebody know? | 00:43 |
| broder | DawnLight: good question. i'm not really sure. my guess would be either in lightdm, but i don't know | 00:44 |
| broder | you might want to send mail to ubuntu-desktop and ask for help | 00:44 |
| broder | crossfader: sorry, i don't know anything about nfs-root. this channel is mostly for development, not support. you should try asking in #ubuntu (or possibly #ubuntu-de - i don't know how occupied that channel is) | 00:45 |
| stgraber | broder, DawnLight: lightdm would be the wrong place for this, gnome-session sounds better or wherever the current 3d/2d check is. #ubuntu-desktop or ubuntu-desktop@lists.ubuntu.com is probably the best place to ask. | 00:45 |
| crossfader | thanx broder | 00:46 |
| crossfader | i try that | 00:46 |
| crossfader | cu | 00:46 |
| DawnLight | thanks a lot! | 00:46 |
| broder | stgraber: hmm, ok. i thought lightdm hooked into that, but *shrug* | 00:46 |
| stgraber | broder: it does indeed call the nux check and cache it to make login faster but that's on top of the existing gnome-session hook | 00:49 |
| * broder nods | 00:49 | |
| stgraber | broder: doing it in lightdm would mean the code wouldn't work with LTSP or with KDM which are the biggest reason why the check is currently being done in both lightdm (for speed reason) and gnome-session (if no cached result from lightdm) | 00:50 |
| broder | got it | 00:50 |
| stgraber | broder: did you find the answer to your upstart question (related to "stop" IIRC)? | 00:52 |
| broder | stgraber: nope. i'm trying to evaluate https://code.launchpad.net/~serge-hallyn/ubuntu/precise/bluez/bluez-respawn/+merge/95667 | 00:52 |
| stgraber | patch looks sane | 00:54 |
| stgraber | stop + exit 0 will have upstart keep the job as stopped and not issue any error message | 00:54 |
| broder | the stop is in the pre-start, incidentally | 00:54 |
| stgraber | exit 1 + respawn would likely make upstart try to spawn it again a few times for no good reason | 00:54 |
| stgraber | yep, that's fine, "stop" is usually done in pre-start to prevent the job from starting | 00:55 |
| stgraber | I believe hallyn made that change based on what he did in the lxc.conf and lxc-net.conf jobs that have a similar check | 00:56 |
| broder | cool. i'll go ahead and upload, then | 00:56 |
| broder | thanks for the help | 00:56 |
| stgraber | np | 00:56 |
| slangasek | stgraber, broder: FWIW I don't consider variables like BLUETOOTH_ENABLED to be a very good reason to support /etc/default files | 00:58 |
| slangasek | I would rather see that cleaned up entirely | 00:58 |
| slangasek | (I've railed against such /etc/default usage even in Debian where everyone's still using init scripts; and with upstart jobs it's just silly to use such a method to disable jobs) | 00:59 |
| broder | slangasek: hmm, what's your preferred approach for avoiding regression for users that are currently using the variable? | 01:00 |
| stgraber | slangasek: well, in this case /etc/default/bluetooth contains a bit more than just that single variable, but I definitely agree we should never introduce a /etc/default/blah file just for that. Though handling the upgrade path is a bit tricky if we want to start removing these. | 01:00 |
| broder | (it predates bluetooth being an upstart job) | 01:00 |
| broder | there are also other variables in /etc/default/bluetooth | 01:00 |
| slangasek | broder: well, I don't consider it a regression in any meaningful sense; but if you care about preserving that admin preference, I'd rather see it converted to an upstart override on upgrade | 01:01 |
| slangasek | stgraber: yes, /etc/default/bluetooth contains *three* variables for disabling services, two of which are obsolete no-ops ;) | 01:01 |
| slangasek | ah, no, perhaps the other two aren't obsolete, but they're just unrelated to the current upstart job | 01:02 |
| stgraber | btw, do we have a tool to easily enable/disable upstart jobs (writting the override file for us) or is that still on the todo? | 01:03 |
| slangasek | still on the todo | 01:03 |
| slangasek | but for a one-time upgrade issue, it's easy enough to do echo manual >> /etc/init/bluetooth.conf.override | 01:04 |
| slangasek | (or is that /etc/init/bluetooth.override?) | 01:05 |
| broder | bluetooth.override | 01:05 |
| * slangasek nods | 01:05 | |
| broder | ok, i guess i'll work on adjusting the initscript and adding some upgrade logic, and probably a NEWS.Debian entry? | 01:06 |
| slangasek | initscript? maintainer script? | 01:06 |
| broder | well, removing the variable from the .default file and upstart job | 01:07 |
| slangasek | right | 01:07 |
| slangasek | I wouldn't personally bother with a NEWS.Debian, but I guess there's nothing wrong with that | 01:07 |
| stgraber | right, so have a preinst source /etc/default/bluetooth, if disabled, write the override file (and print something for the user), then ship a new /etc/default/bluetooth without the BLUETOOTH_ENABLED part | 01:07 |
| slangasek | postinst, not preinst | 01:07 |
| slangasek | no need to do it before unpacking the new version of the package - that just makes rollbacks more complicated | 01:08 |
| broder | slangasek: i'd like to leave a note somewhere for people who expect the variable to be there, and if i set a precedent of putting it in the .default file, it makes it harder to delete the .default file if the other 2 variables are ever obsoleted | 01:08 |
| slangasek | oh, except this is a conffile and we want to avoid a conffile prompt, don't we | 01:09 |
| stgraber | I guess you could even go as far as checking the checksum of /etc/default/bluetooth with BLUETOOTH_ENABLED=0 to avoid the config update prompt | 01:09 |
| broder | oh yeah, i'd prefer to avoid the conffile prompt if i can | 01:09 |
| stgraber | slangasek: right, my understanding was that we need the old /etc/default/bluetooth to do the check, so we need preinst | 01:09 |
| stgraber | slangasek: (same for the checksuming) | 01:09 |
| slangasek | broder: sure; my personal inclination would be to just spit a message out about it on stdout when the package is upgraded if this needed to be done and otherwise be silent, but NEWS.Debian isn't clearly a *wrong* thing to do | 01:10 |
| * broder hates dealing with conffile upgrades | 01:11 | |
| broder | can we just leave it for now and deal during q? :) | 01:12 |
| slangasek | if you wish ;) | 01:12 |
| broder | i'm not exceptionally confident in my ability to get this right, and i'd like to focus on getting things out of the sponsorship queue today | 01:13 |
| slangasek | broder, stgraber: checked bluez source, the other two default vars are no-ops in the current package | 01:13 |
| slangasek | so that reduces the upgrade logic to preinst: source, check var, write override file, remove conffile | 01:14 |
| stgraber | I think it'd be best to wait to have a tool to write/remove override files before we start converting things to them. Granted it's very easy to write (just one line) and it's documented in init(5) but I think it could do with a bit more visibility and having a tool to update the override should fix that. | 01:14 |
| stgraber | so my opinion is that we should keep the current /etc/default/bluetooth for 12.04 and maybe start being aggressive (and consistent) on how to disable the jobs starting in 12.10 | 01:15 |
| slangasek | stgraber: well in that case, I would argue to just drop support for /etc/default/bluetooth from the package entirely *without* a transition to a .override, which is generally what we've done in upstart conversions | 01:15 |
| stgraber | so that's not just bluetooth but anything using a similar hack (which AFAIK is a fair amount of packages) | 01:15 |
| slangasek | no, almost all packages that have preserved /etc/default handling when converted to upstart jobs have done so because of non-trivial variables | 01:16 |
| slangasek | not just for enable/disable handling | 01:17 |
| broder | i'm inclined to agree with stgraber just because it decreases the flame coefficient | 01:17 |
| broder | but i will also likely not be writing much/any of the code involved, so that's easy for me to say :-P | 01:18 |
| slangasek | bluetooth is the package that's inconsistent here | 01:18 |
| slangasek | bluez rather | 01:18 |
| slangasek | it's spawning a pre-start script for no reason other than to check whether the service should be started. That's unidiomatic in upstart, and slows the boot down | 01:18 |
| broder | is that actually true in practice? i'd expect ureadahead to mostly nullify the impact | 01:20 |
| broder | (performancewise - i accept that it's unidiomatic) | 01:20 |
| slangasek | you still have the cpu cost of spawning another shell and doing stuff | 01:20 |
| slangasek | I'm not saying "this script kills our boot performance" - but boot performance is why on the whole we don't do this | 01:20 |
| stgraber | slangasek: I see that on my system apport, cryptdisks, irqbalance and qemu-kvm all have kept their ENABLE/DISABLE variables in /etc/default/ when converted to upstart, though indeed most of them have at least another variable coming from the file | 01:21 |
| stgraber | so I think if we want to make the switch to .override (which is perfectly fine with me, I'm happy to see it used), we should do it consistently for all packages using upstart | 01:22 |
| stgraber | s/using upstart/shipping an upstart job/ | 01:22 |
| stgraber | and only keep /etc/default/<package> for other variables (if any is left) | 01:22 |
| slangasek | stgraber: the line I'm drawing is with jobs spawning an extra pre-start process *just* to check whether to start the service. There are other incremental improvements we can make elsewhere to reduce the use of /etc/default, but they're in general a lot harder | 01:23 |
| slangasek | cryptdisks and irqbalance parse their files for other variables and do it as part of a 'task' script; apport is a special case because the file is being regularly modified by the package (because we change whether to enable apport at different times in the release cycle); qemu-kvm actually doesn't use it to disable the service at all | 01:25 |
| stgraber | doing that parsing in a task script sounds wrong to me though, it'll indeed avoid spawning an extra shell but will result in the job marked as running even though it's not | 01:27 |
| slangasek | I don't think so, not if the job exits non-zero? | 01:28 |
| stgraber | anyway, I understand your interest in saving a bit of boot time but I'd really much prefer doing something consistent and not have bluetooth be the only one doing it right as I think it'd just confuse our users... | 01:28 |
| stgraber | if the exit non-zero it should be then marked as stopped indeed and will log a failure | 01:29 |
| stgraber | the logging a failure part is the one that would be avoided with a check in pre-start + call to stop | 01:29 |
| stgraber | (though I guess you can call "stop" from the task script too) | 01:30 |
| slangasek | stgraber: as far as I'm concerned, "doing it right" is to drop the variable from /etc/default/bluetooth, period. | 01:38 |
| slangasek | whether the maintainer script helpfully migrates that setting to a .override for the user is secondary | 01:39 |
| slangasek | we never should have been using /etc/default for this in the first place, and there's no justification for carrying it forward with upstart | 01:39 |
| User_007 | broder, i installed bzr, got the branch, made my changes, commited... and now how to make a .changes? (i tried bzr -bd -S and it said -bd is unknow command) | 01:41 |
| broder | User_007: bzr bd -S - no dash before the bd | 01:41 |
| User_007 | ok | 01:41 |
| User_007 | still unknow | 01:42 |
| broder | User_007: you may need to install the bzr-builddeb package if you haven't already | 01:42 |
| User_007 | ok | 01:42 |
| === L3top_ is now known as L3top | ||
| broder | slangasek: ok, say i decided to handle transition the /etc/default variable to an override file in the preinst. do i need to roll that back somewhere in the case of an upgrade failure? | 01:48 |
| broder | http://paste.ubuntu.com/867621/ is what i have so far | 01:52 |
| broder | http://wiki.debian.org/MaintainerScripts is kind of short on information on what to do if the unpack fails | 01:55 |
| mbiebl | broder: I probably wouldn't do it on every upgrade and check if the override file already exists | 02:07 |
| mbiebl | so you don't overwrite any custom local configuration | 02:07 |
| broder | mbiebl: ah, sure. good point. let me adjust | 02:08 |
| broder | mbiebl: ok, i think http://paste.ubuntu.com/867637/ should better handle the .override file existing already | 02:13 |
| broder | (and it will only run on one upgrade) | 02:13 |
| User_007 | broder, i got some problems with signing the .changes | 02:19 |
| broder | User_007: if you haven't already created a gpg key, you should probably read through http://developer.ubuntu.com/packaging/html/getting-set-up.html | 02:20 |
| mbiebl | broder: looking at the Architecture: line, I'm wondering why it doesn't use linux-any | 02:22 |
| broder | mbiebl: eh, that's not the sort of thing i'd generally introduce as an ubuntu change | 02:23 |
| User_007 | broder, i have already done everithing.... it seems bzr wants to use my computer name (user@computer) to find my gpg key | 02:25 |
| broder | User_007: it uses the debian/changelog entry to figure out which key to use | 02:25 |
| broder | so you probably didn't have DEBEMAIL set at the time you created the changelog entry | 02:25 |
| mbiebl | broder: going to file a bug against the Debian package | 02:25 |
| User_007 | humm | 02:25 |
| broder | mbiebl: cool, sounds like a good plan. do my changes seem correct to you? | 02:26 |
| broder | (given slangasek's design goals) | 02:26 |
| mbiebl | haven't checked the updated pastebin yet | 02:26 |
| broder | k | 02:27 |
| User_007 | thanks a lot broder ! | 02:34 |
| broder | glad to help :) | 02:34 |
| User_007 | :) | 02:34 |
| slangasek | broder: if it's done in the preinst, yes, you need to roll it back in the prerm | 02:48 |
| broder | slangasek: the failed-upgrade case? | 02:49 |
| slangasek | yep | 02:49 |
| broder | i guess i need some sort of flagfile to tell if i was the one to edit the override | 02:50 |
| broder | is there a convention on where i would do that? | 02:51 |
| micahg | doko: you seemed to have dropped my fix for icedtea-web with the new upload, someone already has a merge proposal with the same fix as last time, so I"m going to sponsor it | 02:57 |
| broder | @pilot out | 03:25 |
| === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === wzssyqa1 is now known as wzssyqa | ||
| === wzssyqa is now known as Guest34446 | ||
| === sssssxxxx is now known as wzssyqa | ||
| === wzssyqa1 is now known as wzssyqa | ||
| === juliank0 is now known as juliank | ||
| === Quintasan_ is now known as Quintasan | ||
| shnatsel | cjwatson: I've patched Casper for elementary OS recently and discovered that recent additions are under-documented. Here's a fix: https://code.launchpad.net/~shnatsel/ubuntu/precise/casper/comments-on-flavour/+merge/95788 | 15:51 |
| fishor | hallo all, i currently have some linker dependensies problems on ubuntu12.04, the problems are with *.la files | 16:37 |
| fishor | my question is. should actually *.la files be included to the packages or not | 16:37 |
| fishor | becouse some are missing, some included | 16:38 |
| === yofel_ is now known as yofel | ||
| PaoloRotolo | Hi all! | 18:46 |
| === tkamppeter_ is now known as tkamppeter | ||
| Ampelbein | fishor: la files shouldn't be included in new packages. For existing packages they should be removed once no other package references them. | 18:51 |
| JontheEchidna | on | 19:06 |
| JontheEchidna | oops | 19:06 |
| JontheEchidna | (hit konversation w/ my mousepad accidentally mid-typing) | 19:06 |
| fishor | Ampelbein, thx.. i trying to compile cheese from source bat there are still some not existing la dependencies. how can i find package with making me troubles | 19:15 |
| fishor | i mean not existing la is not problem, but why configure script still include it? | 19:16 |
| Ampelbein | fishor: 'grep "NAME_OF_THE_LA_NOT_FOUND" /usr/include -r' | 19:16 |
| Ampelbein | fishor: Can you pastebin the error? | 19:17 |
| fishor | Ampelbein, http://paste.ubuntu.com/868763/ | 19:27 |
| Ampelbein | fishor: try 'grep libatk-1.0.la /usr/lib -r" | 19:28 |
| Ampelbein | fishor: Btw, I can build cheese fine in current precise. | 19:35 |
| === JackyAlcine_ is now known as jalcine | ||
| === jalcine is now known as JackyAlcine_ | ||
| === JackyAlcine_ is now known as jalcine | ||
| === jalcine is now known as JackyAlcine_ | ||
| === JackyAlcine_ is now known as jalcine | ||
| === jalcine is now known as JackyAlcine_ | ||
| fishor | Ampelbein, thx... i found the files. thay are not from precise | 20:30 |
| === JackyAlcine is now known as jalcine | ||
| chromaticwt | will 12.04 be 64 bit? | 21:14 |
| JanC | chromaticwt: Ubuntu has been available as both 32-bits & 64-bits since 2004... | 21:15 |
| JanC | and that won't change for 12.04 | 21:16 |
| chromaticwt | wow, I don't know why I didn't realize this. | 21:17 |
| micahg | it was discussed to make it 64 bit by default | 21:17 |
| JanC | well, it has been 64-bit by default for servers | 21:18 |
| JanC | I don't think 64-bit makes sense for desktops right now | 21:19 |
| JanC | 64-bit kernel + 32-bit userspace might make more sense for most users... | 21:20 |
| chromaticwt | JanC: If 12.04 is 64 bit by default will I still be able to run all of my favorite apps on it? | 21:21 |
| JanC | chromaticwt: you can run 32-bit apps on a 64-bit system, so it shouldn't be a problem really | 21:22 |
| chromaticwt | ok | 21:22 |
| JanC | but AFAIK the default for 12.04 desktop will still be 32-bit (but with PAE required) | 21:24 |
| chromaticwt | ok, I noticed that beta1 is available for download, so I'm going to upgrade to 64 bit beta1. | 21:39 |
| chromaticwt | when 12.04 stable is released will I only need to issue apt-get upgrade to upgrade to the stable release? | 21:39 |
| micahg | dist-upgrade, but yes | 21:40 |
| stgraber | yes, if you do upgrades regularly, you'll always be on whatever is the current milestone | 21:41 |
| stgraber | if you installed alpha-2 and did your updates, you're currently on something a bit newer than beta1 | 21:41 |
| chromaticwt | micahg: I need to do dist-upgrade even when upgrading from beta to release? | 21:44 |
| JanC | actually, you need to do dist-upgrade even after the release :P | 21:44 |
| micahg | chromaticwt: yes, as there will likely be new packages | 21:44 |
| chromaticwt | ok | 21:44 |
| JanC | e.g. new kernel packages | 21:44 |
| micahg | and dist-upgrade is preferable, but you need to be careful during the dev release or you can accidentally remove half your system at some points (update-manager is usually safer) | 21:45 |
| chromaticwt | ok | 21:45 |
| * JanC prefers Synaptic ;) | 21:45 | |
| chromaticwt | so this is my plan. I want to upgrade to beta1 by doing a clean 64 bit install. then I will issue apt-get upgrade to update until release. once 12.04R is released I will use update-manager to upgrade to release. | 21:47 |
| chromaticwt | I want the most stable system possible. should I just wait until release to upgrade? | 21:47 |
| chromaticwt | I don't mind testing beta. | 21:47 |
| chromaticwt | not to flood anymore about this. | 21:47 |
| JanC | chromaticwt: no reason to use apt-get upgrade if you prefer a GUI... | 21:48 |
| chromaticwt | JanC: personally I prefer the command line for most tasks. | 21:48 |
| JanC | well, no need for update-manager to get the final release then ;) | 21:48 |
| chromaticwt | JanC: so I should use apt-get dist-upgrade or whatever? | 21:49 |
| JanC | use apt-get dist-upgrade, but be sure to check what it wants to do before you allow it to remove packages | 21:50 |
| === albrigha is now known as Guest26930 | ||
| chromaticwt | ok | 21:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!