[00:27] <psusi> external media is mounted with the user and group of the logged in user, which works great for vfat and udf, but not ext[234].  I've been pondering the idea of patching the kernel to allow those options to work with ext[234] and override permissions on external media.. anyone have any thoughts about that?
[00:27] <psusi> mac seems to have an option you can toggle on its hfs+ disks to enable or disable permissions... seems handy for removable media
[00:28] <psusi> and shouldn't be too hard to implement
[00:38] <RAOF> That naievely sounds like a good idea.
[00:38] <RAOF> ?
[00:40] <ebroder> What should the UID of a file I create on an ext* fs mounted with this option?
[00:41] <ebroder> Also setuid seems like it's going to be problematic
=== sanchaz is now known as sanchaz-away
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
[02:10] <psusi> ebroder, well, the way it works with udf is that the on disk uid is -1 when you are the interactive user and it was mounted with uid=yourid, then if someone else mounts that disk, the -1 is turned into their id on read
[02:12] <psusi> a few years back I patched udf to accept additional options to give more control over it... originally it only applied the uid option as a default if it was already -1 on disk, if it was something else then it used that... I added options allowing you to specify that it should override any on disk id
[02:12] <ebroder> What happens if you mount a drive that has files with uid -1 without a forced uid?
[02:13] <psusi> you mean without the force option I added, or without any uid= option?
[02:13] <ebroder> Without any uid= option
[02:13] <psusi> then it is owned by -1
[02:13] <psusi> err, wait, no
[02:13] <psusi> it's owned by root
[02:14] <psusi> yea... -1 on disk gets translated to 0 by default, or whatever you specify in the uid= mount option
[02:14] <ebroder> ok. so i coerce someone (or something) into mounting a filesystem with uid=me, make a file setuid, then coerce someone (or something) into mounting it without a uid= option
[02:14] <psusi> typically removable media is mounted with the nosuid option
[02:14] <psusi> and/or noexec
[02:15] <ebroder> do you know if, say, udisks does that?
[02:16] <psusi> yep, nosuid, nodev,uid and gid options
[02:16] <ebroder> and it looks like it doesn't allow the user to override with suid. that's good, at least
[02:21] <psusi> yea, the only problem is that the uid option is ignored except by vfat, ntfs, and udf ( and even with udf it is only used if the on disk id is -1, which it will be as long as you created the file mounted the same way )
=== manusheel_afk is now known as manusheel
[02:30] <calamari> hey.. just spent the last few *hours* compiling the kernel and wanted to just say THANK YOU to everyone creating packages and updates for us, I have a new appreciation for the dedication it must take to do this day after day.  Thanks a lot!
[02:48] <psusi> lol
=== manusheel is now known as manusheel_afk
=== dendro-afk is now known as dendrobates
[04:07] <lool> mdeslaur: I'm not sure how I relate to LP: #631980, but this seems ok
[04:12] <mdeslaur> lool: I asked because you're on the linaro release team...that's all
[04:18] <lool> mdeslaur: Oh ok; thanks
=== almaisan-away is now known as al-maisan
=== _LibertyZero is now known as LibertyZero
[06:48] <lool> Hmm something corrupts my usb-creator-ed USB keys on reboot
[06:48] <lool> I get dropped to a grub rescue shell if I boot them more than once
=== _LibertyZero is now known as LibertyZero_
[07:19] <jfer> hi, i am new to packaging and i was wondering what you should put in the section part of the control file
[07:23] <RAOF> jfer: Debian policy has a list of current sections; a google search for “debian policy sections” will get you http://www.debian.org/doc/debian-policy/ch-controlfields.html as the first link, which will link you through to http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections which ends up http://packages.debian.org/unstable/
[07:24] <JanC> looking at what other, similar packages use might be helpful too
[07:37] <dholbach> good morning!
=== hanska is now known as dapal
[09:17] <pitti> yofel: yes, file-bug is supposed to be implied; I assigned the bug to me
=== MacSlow is now known as MacSlow|lunch
[12:02] <mdz> pitti, ping
=== manusheel_afk is now known as manusheel
[12:15] <seb128> mdz, he's taking a swap day after travel today
[12:15] <mdz> seb128, ah, thanks, I'll send email
[12:15] <seb128> mdz, so maybe better to let some ping context
[12:16] <seb128> ok
=== MacSlow|lunch is now known as MacSlow
[13:35] <hdon> hi all. if i want to compile with -m32 from my 64-bit system, what packages should i install?
=== yofel_ is now known as yofel
[15:37] <cr3> cjwatson: when I preseed a ubiquity install with mirror/http/hostname, it seems that sources.list still gets us.archive.ubuntu.com. might this be a known problem?
[15:38] <cr3> cjwatson: by the way, that's for lucid and I could confirm if the problem is also on maverick if you'd like
[15:39] <cjwatson> cr3: can I see your full preseed file, please?
[15:48] <cr3> cjwatson: https://pastebin.canonical.com/39485/
=== beuno is now known as beuno-lunch
[15:53] <cjwatson> cr3: I'm not sure.  Can I have a DEBCONF_DEBUG=developer syslog?
[15:53] <cr3> cjwatson: also, while pitti's out, might you happen to know why the i386 linux-meta package doesn't seem to be published to the archive even though launchpad.net says that the build is done: https://launchpad.net/ubuntu/lucid/+source/linux-meta/2.6.32.26.28
[15:54] <cjwatson> it is published
[15:55] <cjwatson> well, it's published on the master system anyway
[15:55] <cr3> cjwatson: I'm only seeing 2.6.32.26 images for amd64 here: http://archive.ubuntu.com/ubuntu/pool/main/l/linux-meta/
[15:55] <cjwatson> probably just waiting for mirrors to catch up
[15:55] <cjwatson> (note that archive.ubuntu.com is a mirror network itself)
[15:56] <mathiaz> statik: hi - seems like you've started to package Graphite - http://graphite.wikidot.com/ - Graphite - Enterprise Scalable Realtime Graphing
[15:56] <mathiaz> statik: what's the status of packaging?
[15:57] <cr3> cjwatson: ok, so I should start seeing them soon, thanks for the confirmation. I'll try to get those DEBCONF_DEBUG logs for you soon
[15:57] <cjwatson> which is odd given that the timestamp is five hours ago though
[15:58] <cjwatson> cr3: I recommend asking #is (internal IRC), since it looks to me as though the mirroring is stuck
[15:58] <mathiaz> cjwatson: hi - do you have any hint to fix bug 448682?
[15:58] <ubottu> Launchpad bug 448682 in couchdb (Ubuntu Karmic) "Cannot stop couchdb using /etc/init.d/couchdb after package install" [Medium,Triaged] https://launchpad.net/bugs/448682
[15:58] <cjwatson> cr3: http://archive.ubuntu.com/ubuntu/project/trace/cocoplum.canonical.com is timestamped 07-Nov-2010 20:18
[15:58] <mathiaz> cjwatson: it seems to be related to blocked signals by dpkg/apt
[15:58] <jpds> cjwatson / cr3> mirroring fixed.
[15:58] <cr3> cjwatson: good point, launchpad.net says that the image was built on 2010-11-05, I'll hop into #is now
[15:59] <cr3> jpds: too quick for me :)
[16:01] <cjwatson> mathiaz: a workaround is easy - set SIGINT back to SIG_DFL on starting the daemon.  as for the proper fix, I'm not sure.  it would be helpful to start by stracing everything in sight to figure out what's actually ignoring SIGINT
[16:02] <cjwatson> (you will find that dpkg ignores SIGINT in the parent process while the child maintainer script is running, but that doesn't count - you want stuff actually on the path to forking erlang)
[16:02] <cjwatson> there's some suspicious code in apt
[16:02] <cjwatson> err, SIGHUP, not SIGINT
[16:07] <Keybuk> cjwatson: is the signal even in the process signal mask?
[16:07] <mathiaz> Keybuk: SigIgn: 0000000000001007
[16:07] <cjwatson> Keybuk: there's information in the bug ...
[16:07] <cjwatson> Keybuk: apt's code is suspicious to me because it ignores signals *before* forking child processes, not after as is more usual
=== jdstrand_ is now known as jdstrand
[16:08] <Keybuk> masking signals across a fork() is a common idiom
[16:08] <Keybuk> it's used when the signal handler has complex code, e.g. modifies lists of pids
[16:08] <cjwatson> sure, but it's ignoring stuff a la system(), not quite the same thing
[16:08] <Keybuk> otherwise you could interrupt the fork+record pid mechanism at a bad point
[16:08] <cjwatson> I know, but that's not what's happening
[16:09] <Keybuk> sure, it's probably someone picked up a "I must mask signals" meme without understanding it
[16:09] <cjwatson>       /* Mask off sig int/quit. We do this because dpkg also does when
[16:09] <cjwatson>          it forks scripts. What happens is that when you hit ctrl-c it sends
[16:09] <cjwatson>          it to all processes in the group. Since dpkg ignores the signal
[16:09] <cjwatson> but they did it at the wrong point
[16:09] <cjwatson>          it doesn't die but we do! So we must also ignore it */
[16:09] <mathiaz> cjwatson: I've tried to insert a 'trap true 1' in the couchdb shell script
[16:09] <mathiaz> cjwatson: but it seems like it doesn't work as expected
[16:10] <mathiaz> cjwatson: is there another way to unblock signal 1?
[16:10] <cjwatson> mathiaz: well, if you've gone through the shell to figure out exactly how that's implemented ...
[16:10] <cjwatson> mathiaz: I meant calling sigaction in the daemon itself
[16:10] <cjwatson> I'm surprised that more daemons don't have this kind of problem, though
[16:10] <cjwatson> maybe they do and we just don't notice
[16:11] <mathiaz> cjwatson: http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/natty/couchdb/natty/annotate/head%3A/bin/couchdb.tpl.in#L225
[16:11] <mathiaz> cjwatson: ^^ this is where the erlang process is created
[16:11] <cjwatson> I mean do it inside whatever $command is
[16:12] <cjwatson> in couchdb itself
[16:12] <mathiaz> cjwatson: ok
[16:13] <cjwatson> or create a tiny C wrapper that does  struct sigaction sa; memset (&sa, 0, sizeof sa); sa.sa_handler = SIG_DFL; sigemptyset (&sa.sa_mask); sa.sa_flags = 0; sigaction (SIGHUP, &sa, NULL);  and then execs the program
[16:13] <cjwatson> this is just a crappy workaround though
[16:13] <mathiaz> cjwatson: given that erlang doesn't seem to support linux signal (http://stackoverflow.com/questions/2459672/erlang-linux-signal-handling)
[16:14] <mathiaz> cjwatson: it seems that the C wrapper is a good option
[16:14] <cjwatson> that's a bit rubbish
=== deryck is now known as deryck[lunch]
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[16:45] <psusi> cjwatson: speaking of signals and debconf, the other day I inadvertantly got postfix installed while installing something else and when the debconf for it came up, could not cancel out or ctrl-c, and it kept running after I closed the terminal.. shouldn't it die on SIGHUP?
[16:45] <cjwatson> psusi: we weren't speaking of signals and debconf; we were merely speaking of signals
=== beuno-lunch is now known as beuno
[16:46] <psusi> ohh... thought you were talking about them being ignored when dpkg was running child processes
[16:46] <cjwatson> psusi: debconf ought to die on SIGHUP, but the very same apt bug referred to above probably means that it never sees it
[16:46] <cjwatson> psusi: debconf != apt/dpkg
[16:49] <psusi> cjwatson: btw, I proposed merging branches to drop the patches removing the 'p' from the partition device names of dmraid disks in dmraid and parted... I assume you just didn't have time to do that in maverick, or did some reason come up not to?
=== al-maisan is now known as almaisan-away
[16:51] <cjwatson> psusi: it was too late in the cycle by the time I realised it was dmraid and not lvm2 that needed to be synced with - thanks for your patches, I plan to merge them in maverick
[16:54] <psusi> cjwatson: you mean natty, or going to maverick-updates?
[16:56] <mathiaz> JamesPage: where is the zookeeper request for removal?
[16:56] <psusi> I'm still waiting to hear back from a user testing my ppa with those patches applied to fix grub installing on his dmraid where the name ends in digits so I think it can't identify the base disk name vs partition without the 'p'
[16:56] <mathiaz> JamesPage: for bug 666028
[16:56] <ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
[16:56] <JamesPage> mathiaz: I'll just dig out the details.
[16:56] <mathiaz> JamesPage: could you also prepare a branch to fix the bug in natty as well
[16:56] <mathiaz> JamesPage: ?
[16:57] <mathiaz> JamesPage: the first step to get an SRU is to get the bug fixed in the development release
[16:57] <JamesPage> mathiaz: yes (for bug 666028/natty)
[16:57] <ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
[16:59] <psusi> Keybuk: I've been working with updating lvm2 to a new upstream release with --merge support and you wrote a patch to prevent opening disks for write access when activating to prevent a feedback loop where change causes activate causes open for write causes change... why does open for write cause change, and why do we activate all vgs on change, as opposed to just add?
[17:00] <Keybuk> open for write causes an inotify IN_CLOSE_WRITE on the block device
[17:00] <Keybuk> udevd listens for those, and will synthesise a "change" event for the block device
[17:00] <Keybuk> this means that if you create a lv, then run mke2fs on it
[17:00] <Keybuk> you get a "change" event
[17:00] <Keybuk> which means udevd will re-run blkid, and update the UUID/LABEL symlinks to the new filesystem
[17:01] <psusi> ahh... ok... that makes sense... but why vgchange -a y?
[17:01] <Keybuk> likewise, if the pv is inside an md, you have to activate vgs on "change"
[17:01] <Keybuk> because only a change of a md singifies it's ready
[17:01] <Keybuk> you may be confusing the "change" event of the lv with the "change" event of the block device containing the pv
[17:01] <psusi> ohh... when it's added it isn't yet actually readable?
[17:01] <Keybuk> correct
[17:01] <psusi> ahhh
[17:01] <Keybuk> add /dev/md0 - not ready
[17:02] <Keybuk> change /dev/md0 - ready, run vgchange -a -y
[17:02] <psusi> yea, only talking about change on the partition device used as pv
[17:02] <Keybuk> add /dev/dm0 - not ready (haven't yet made a filesystem in it)
[17:02] <cjwatson> psusi: only really interested in doing it for natty, sorry, yes, I meant that
[17:02] <Keybuk> mke2fs /dev/dm0 causes:
[17:02] <Keybuk> change /dev/dm0 - ready, symlinks to the e2fs filesystem now visible
[17:02] <Keybuk> right
[17:02] <Keybuk> so we can't make assumptions about the behaviour of the partition device used as a pv
[17:02] <psusi> Keybuk: got ya...
[17:02] <Keybuk> not all devices are ready on add, in fact, the majority of multiple-block-device devices *are not* ready on add
[17:03] <Keybuk> so we also run on change
[17:03] <JamesPage> mathiaz:  zookeeper removal is under Debian bug#602694
=== kenvandine_ is now known as kenvandine
[17:05] <lifeless> whats 'https://launchpad.net/~ubuntu-irc-members' all about?
[17:05] <Keybuk> I think it means you've been a member on IRC
[17:06] <dholbach> jussi, ^
[17:07] <jussi> lifeless: exactly the same as kubuntu members or edubuntu members etc, but with irc as the contribution.
[17:07] <kees> did vte just stop paying attention to the gnome browser settings?? grrr
[17:07] <lifeless> jussi: this seems very odd
[17:08] <lifeless> jussi: I hadn't heard of it
[17:08] <lifeless> jussi: and if its giving our ubuntu *membership* as a result, I wouldn't have expected to be just added to the group without communication.
[17:09] <lifeless> jussi: (not to mention that I'm already an Ubuntu member ... so it seems redundant to boot)
[17:09] <jussi> lifeless: we did a cross check of ops who are members, and added them automatically. this group will be the people who have the opportunity to vote for the IRCC.
[17:09] <JamesPage> mathiaz: question re bug 666028 and Natty; should this fix be a point release i.e. ubuntu3.3 like it is for Maverick?
[17:09] <ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
[17:10] <mathiaz> JamesPage: yes - for maverick ubuntu3.3
[17:10] <mathiaz> JamesPage: for natty - ubuntu4
[17:10] <lifeless> jussi: Some communication about this would have been nice. Being added to teams without discussion feels pretty uncomfortable.
[17:11] <JamesPage> mathiaz: OK
=== dendrobates is now known as dendro-afk
[17:11] <jussi> lifeless: you have a fair point. I will note to make sure that all are aware next time.
[17:13] <gbs> why $(TOPDIR) doesn't come by default in ubuntu?
[17:14] <gbs> export TOPDIR=$(pwd) in bashrc
[17:15] <ScottK> jussi: Why is the polity for IRCC to be limited to Ops?  Don't all Ubuntu people that use IRC have an interest in that?
[17:16] <jussi> ScottK: it isnt
[17:16] <jussi> ScottK: the ops were auto added and cloaked people were given the choice.
[17:16] <ScottK> jussi: Then I don't understand what you just told lifeless.
=== bjf is now known as bjf[afk]
[17:17] <ScottK> I read your message as "consider adding yourself to the team if you feel IRC is a significant part of your contribution to Ubuntu" not "Add yourself to the team if you want to be able to vote for IRCC".
[17:20] <JamesPage> mathiaz: branch uploaded for bug 666028/natty
[17:20] <ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
[17:21] <jussi> ScottK: this is probably not the correct place for this discussion, so feel free to join me in -irc or pm.
[17:22] <mathiaz> JamesPage: your maverick branch should be reviewed against the maverick-updates branch rather than the maverick branch
[17:22] <mathiaz> JamesPage: as it builds on maverick-updates rather than maverick
[17:23] <JamesPage> mathiaz: it should be but for some reason its not; let me take a look.
[17:23] <mathiaz> JamesPage: when the merge proposal is created, maverick-updates should be used instead of maverick (which is the default IIRC)
[17:24] <JamesPage> mathiaz: OK; so if I delete the proposal and re-propose that should sort this out?
[17:24] <mathiaz> JamesPage: yop - that should work out correctly
[17:24] <JamesPage> mathiaz: OK - on it now...
[17:26] <mathiaz> JamesPage: and you probably wanna push your maverick SRU to lp:~james-page/ubuntu/maverick-updates/openldap/fix-666028
=== deryck[lunch] is now known as deryck
[17:26] <mathiaz> JamesPage: rather than maverick
[17:27] <JamesPage> mathiaz: this would be why it selected maverick rather than maverick-updates as the branch?
[17:27] <mathiaz> JamesPage: yop
[17:28] <mathiaz> JamesPage: the list of branches is a bit confusing when an update has been published
[17:28] <mathiaz> JamesPage: the branches follow the same structure as the pocket (maverick, maverick-updates), etc...
[17:29] <ebroder> cjwatson: do we do a grub-install on release upgrades?
[17:29] <JamesPage> mathiaz: OK; let me trash the merge proposal for maverick-updates and associated branch and I'll re-push
[17:29] <mathiaz> JamesPage: right
[17:29] <mathiaz> JamesPage: it's complicated to get things right
[17:29] <mathiaz> JamesPage: the way I noticed it was by reviewing the diff
[17:29] <mathiaz> JamesPage: associated with the merge proposal
=== dendro-afk is now known as dendrobates
[17:30] <mathiaz> JamesPage: as it had too much information
[17:30] <mathiaz> JamesPage: the diff should represent the difference with the *latest* package published in the archive
[17:30] <JamesPage> mathiaz: yes - I had spotted that; thanks for pointing me in the right direction...
[17:31] <mathiaz> JamesPage: so it can be against the release (ig maverick) or an update (if there was already a package published)
[17:31] <mathiaz> JamesPage: it can even be against -proposed
[17:31] <mathiaz> JamesPage: if there is already a package in -proposed
[17:32] <JamesPage> mathiaz: I see; it all becomes clear....
[17:35] <JamesPage> mathiaz: hmmm; when I try to push to lp:~james-page/ubuntu/maverick-updates/openldap/fix-666028
[17:35] <JamesPage> mathiaz: I get a 'No such distribution series maverick-updates' message
[17:37] <mathiaz> JamesPage: hm - I don't know what's the issue here - may be lifeless or james_w can help here ^^
[17:37] <cjwatson> ebroder: only if grub-pc is upgraded
[17:37] <cjwatson> ebroder: we do grub-install when upgrading grub-pc, and update-grub when upgrading grub-pc or a kernel package, basically
[17:37] <james_w> JamesPage, push just to maverick
[17:38] <ebroder> cjwatson: ok, good. i think my patch to /etc/grub.d/10_linux will work even if the lua module isn't installed, but i'd prefer to not worry too much about it
[17:38] <mathiaz> james_w: and then create a proposal against maverick-updates?
[17:39] <ebroder> cjwatson: in any case, i have a patch to /etc/grub.d/10_linux along with a lua script that it runs, but i'm having a hard time integrating it into the packaging. can you give me some direction on what piece should be installing my lua script into /usr/lib/grub/i386-pc/etc/?
[17:42] <JamesPage> mathiaz: uploading to maverick and then proposing against maverick-updates generates the right diff.
[17:43] <mathiaz> JamesPage: \o/
[17:46] <JamesPage> mathiaz: OK; so bug 666028 now has branches and merge proposals ready for maverick-updates and natty.
[17:46] <ubottu> Launchpad bug 666028 in openldap (Ubuntu) "apt-get install slapd => Can't locate object method "new" via package "Debconf::Element::Noninteractive::Booleam"" [Medium,In progress] https://launchpad.net/bugs/666028
[17:47] <mathiaz> JamesPage: great - looks good to me
[17:47] <mathiaz> JamesPage: I'll sponsor them later today
[17:48] <JamesPage> mathiaz: thanks; finishing my day now so catchup tomorrow....
[17:48] <mathiaz> JamesPage: o^5 - well done
[17:49] <cjwatson> ebroder: I'd be inclined to suggest just putting it in debian/grub-pc.install.in, at least for the moment
[17:51] <ebroder> cjwatson: oh! it's i386-pc on both i386 and amd64, isn't it? i just realized i'm looking at i386-pc on my amd64 machine
[17:51] <slangasek> pitti, cjwatson, jdong: all the bits Linaro needs out of maverick-proposed are published to maverick-updates now, feel free to consider -proposed unfrozen
[17:53] <ebroder> cjwatson: that makes it easier. i should be able to write up a patch once i get back to my machine with all of my credentials
[17:55] <cjwatson> ebroder: yes, the "i386" there refers to the architecture of the boot loader objects
[17:55] <cjwatson> which are always 32-bit when built for the BIOS platform
[17:55] <RoAkSoAx> slangasek: howdy!! I was wondering if you had the time to review the library split for cluster-glue/pacemaker?
[17:57] <slangasek> RoAkSoAx: not at all yet, sorry :/  Hoping to get to it this evening
[17:59] <RoAkSoAx> slangasek: idon't worry abot it L:). Thanks though :)
=== zyga is now known as zyga-afk
[18:25] <bruteforce_allti> Hi, while on local systems(Lucid and Maverick ), I was able to build a package suffecssfully. But when I uploaded(ppa) it in respective series(Lucid and Maverick), all Lucid packages failed to build. While Maverick build successfully.
[18:26] <bruteforce_allti> Build Log http://launchpadlibrarian.net/58724370/buildlog_ubuntu-lucid-amd64.sugar-datastore-0.90_0.90.0-1ubuntu1_MANUALDEPWAIT.txt.gz   and failed because of unsatisfied dependency. After installing, the following source dependencies are still unsatisfied: cdbs(inst 0.4.62+nmu1ubuntu9 ! >= wanted 0.4.75~)
[18:27] <bruteforce_allti> Can anyone please guide me how to solve this and explain why this error is occuring?
=== bruteforce_allti is now known as neeraj
[18:28] <cjwatson> neeraj: you're asking (via Build-Depends) for a version of cdbs considerably newer than what's in luci
[18:28] <cjwatson> *lucid
[18:29] <cjwatson> you will need to figure out what's needing newer features of cdbs, and backport them to whatever is available in lucid
[18:29] <cjwatson> alternatively, perhaps there is a newer version of cdbs in some other PPA somewhere, in which case you can make your PPA depend on that
[18:29] <cjwatson> it's in the web UI
[18:34] <neeraj> cjwatson: ok.  Thats what I thought. Was searching about latest cdbs available in lucid. And yes there is cdbs 	0.4.82  present but in under sugarteam.(while lucid ones were inside sugar-test2).
[18:36] <neeraj> That cdbs 	0.4.82  is in Lucid series
[18:54] <NCommander> cjwatson: ping, you don't happen to have a  copy of the spice seed notes, would you, or know someonw ho does?
[18:56] <ogra_ac> NCommander, i thought i saw them in gobby today
[18:56] <ogra_ac> 8didnt open them though)
[18:56] <NCommander> ogra_ac: there's a doc there, but its empty
[18:56] <ogra_ac> ah
[18:56] <ogra_ac> then ask persia
[18:57] <ogra_ac> if he took the notes, he didnt take them in gobby
[18:57] <persia> I didn't take the notes of that session.
[18:59] <NCommander> ogra_ac: you see the problem :-)
[18:59] <NCommander> I'm going to have to listen to the audio and recreate them
[18:59] <NCommander> ogra_ac: BTW, did you review either of the specs I wrote (I sent you an email about that)
[18:59] <ogra_ac> NCommander, i couldnt get to any mail the last week
[19:00] <ogra_ac> plumbers had the worst network i have ever seen ... redhat needs an elmo ;)
[19:01] <NCommander> ogra_ac: obviously you forgot the internet connection in Holiday Inn, Berlin :-)
[19:02] <ogra_ac> that was still better
[19:02] <NCommander> Ouch
[19:11] <ebroder> SpamapS: i don't have my LP credentials with me - could you fix packageselection-server-n-upstart-server-enhancement to say that maintainer scripts should always use invoke-rc.d, and that there's an outstanding bug that that doesn't result in calling upstart jobs?
[19:18] <SpamapS> ebroder: Sure.. I was just dumping the gobby doc in.
=== tkamppeter_ is now known as tkamppeter
[19:19] <SpamapS> I wonder, if I have an upstart job that pipes to logger, can i use expect fork? I'm guessing no.
[19:21] <SpamapS> Keybuk: poke ^^ ???
[19:23] <SpamapS> hrm...
[19:23] <SpamapS> I am typing out work items and I think this one does need a full specification to explain the rationale.. :-P
[19:25] <psusi> Keybuk: a while back I patched ureadahead to use the tracer in pipe mode instead of log file mode, which eliminated the need for a large trace buffer.  I see you have since lowered the size of the trace buffer to 8mb.. given that would you be interested in pipe mode?
=== lifeless_ is now known as lifeless
=== kklimonda_ is now known as kklimonda
[19:45] <tony_> Hello, my external speakers did not work, but I tweaked with HDA-Analyzer and found that by unmuting two things (in Node[0x0c]) get my external speakers to work. But how can I make this change permanent?
[19:45] <tony_> Because everytime I reboot I have to run HDA-Analyzer and change it again and again.
[19:48] <ScottK> tony_: Help is in #ubuntu.
[19:49] <tony_> ScottK, noboy's answering and I thought it would be too a technical question so I asked here
[19:49] <ScottK> Lack of help in #ubuntu doesn't make it on topic here.  Sorry.
[19:51] <cjwatson> NCommander: afraid I don't, sorry
[19:53] <NCommander> cjwatson: bugger.
[20:00] <pasteeater> siretart: would a comment showing support/interest in your x264 MIR be useful or just noise?
[20:01] <Daniel0108> hi
[20:02] <paddy_> I created a key for launchpad with gpg --gen-key but i cannot find the file i give to launchpad, the key appears in seahorse though
[20:04] <SpamapS> paddy_: you'll want to export that public key to an ASCII armor format and upload it.
[20:05] <lifeless> SpamapS: err, not for launchpad
[20:05] <SpamapS> oh?
[20:05] <paddy_> SpamapS, an .asc file, tried that, gave errror
[20:05] <paddy_> lifeless, what do?
[20:06] <lifeless> https://launchpad.net/people/+me/+editpgpkeys
[20:06] <lifeless> and follow the instructions
[20:07] <lifeless> SpamapS: paddy_: ^
[20:07] <paddy_> lifeless, thanks
[20:12] <SpamapS> lifeless: doh.. if only everything were so simple. ;)
=== zyga-afk is now known as khr
=== khr is now known as zyga
[20:29] <SpamapS> slangasek: ping, do you know if there is an existing place where the "best practices" for upstart in ubuntu are documented? I've googled for a few but maybe you have the definitive answer?
[20:30] <slangasek> SpamapS: what is it you want to practice?
[20:30] <slangasek> adding jobs to packages?
[20:30] <slangasek> there's no documentation for that - it should be documented by way of debian/ubuntu policy
=== bjf[afk] is now known as bjf
[20:31] <SpamapS> specifically in "how to write an upstart job" and "how to manage upstart jobs"
[20:31] <ScottK> SpamapS: The best practice is ask Keybuk.
[20:31] <SpamapS> ScottK: ;)
[20:32] <SpamapS> slangasek: I went through your old IRC class and it had a few things in there that were somewhat non obvious.. stuff like that.
[20:33] <SpamapS> https://wiki.ubuntu.com/MeetingLogs/devweek1007/UpstartJobs
[20:33] <slangasek> SpamapS: yeah, there's work to be done around codifying and documenting this stuff
[20:33] <SpamapS> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-upstart-server-enhancement
[20:34] <SpamapS> slangasek: I'm hoping to do a lot of that work this cycle. :)
[20:34] <SpamapS> including documenting when this is a permanent thing, and when this is "only until upstart bug #x is fixed"
[20:34] <slangasek> SpamapS: if you were to take that meeting log and massage it into a wiki write-up, that would probably be a good start?  And I'd be happy to review for you
[20:34] <SpamapS> slangasek: I intend to do just that.
[20:35] <SpamapS> I think the idea is to make sure we are simply documenting the use cases, and pointing to the man page for details.
[20:36] <SpamapS> Would it make sense to also try to add an EXAMPLES section to man 5 init?
[20:36] <slangasek> I have no strong opinion there
[20:38] <ScottK> SpamapS: I almost always love examples in man pages.
[20:38] <SpamapS> ScottK: agreed, that way it stays close to the software when changes are made.
[20:39] <ScottK> SpamapS: It's generally the first documentation I look at and so if it solves my problem, life is good.
[20:42] <SpamapS> ScottK: right, I think once people find man 5 init, they get a deeper understanding of upstart and cut out the hate, so much of this will serve to push people to that man page.
[21:07] <barry> SpamapS: okay, i've done all i can do for your mp on cheetah :)
=== hanska is now known as dapal
=== xomas_ is now known as xomas
=== zyga is now known as zyga-afk
=== manusheel is now known as manusheel_afk
[22:36] <RAOF> Urgh.  Why does symbol visibility appear to be a compile time rather than link time decision?
[22:42] <syn-ack> That't the way it's always been, RAOF. I think it should be a link time option though
[22:50] <RAOF> syn-ack: It does make it somewhat more difficult to do what I want:)
[22:58] <syn-ack> RAOF: heh
[23:10] <lamont> cjwatson: both of us are too short to use signals.
[23:10] <lamont> just sayin'
[23:14] <Iraqi> there are people the power off on PC and after want running ubuntu 10 will not running so how fix it please?
[23:24] <SpamapS> barry: thanks for the review though, preparing a patch for the debian experimental cheetah
[23:32] <bryceh> persia, is it still proper for people who want to become core dev to apply for motu first?  There's a regular xorg contributor (now canonical employee) who is aiming to gain core-dev.  Should he start by applying for MOTU or just shoot for core-dev directly?
[23:34] <syn-ack> good afternoon, SpamapS.
[23:39] <persia> bryceh, There's certainly no need to apply for MOTU prior to applying for core-dev.  That said, the requirements for core-dev have become rather more strict than previously, as other options have become available.
[23:40] <persia> Depending on the breadth of packaging experience, it is often appropriate for candidates for core-dev to previously have been approved as some other sort of Ubuntu Developer, simply to show responsibility to the archive and skill in packaging.
[23:41] <persia> Depending on the prior work of this individual, another option would be to apply for upload rights to specific packages of interest (those that are considered part of X), or similar.
[23:52] <bryceh> persia, ok thanks
=== dendrobates is now known as dendro-afk