[00:13] <smoser> skaet, around ?
[00:34] <broder> slangasek: you need to restart gnome-terminal
[00:34] <broder> the new version of the library embeds the termcap instead of shipping it as a separate file
[00:34] <broder> rather, all of your terminals
[00:39] <skaet> smoser,  just back from dinner,  what's up?
[01:12] <kees> I am impressed that the resolvconf postinst contains a detailed error about having an immutable resolv.conf file :)
[01:15] <ajmitch> there are probably quite a few blog posts telling people to make resolv.conf immutable to stop it being clobbered :)
[01:15] <kees> indeed. it's the only way I could get n-m to behave itself.
[01:15] <stgraber> ajmitch: no, the recommendation is to simply replace the symlink by a regular file
[01:15] <kees> and it looks like resolvconf DTRT for my system, which I find very pleasing
[01:16] <stgraber> ajmitch: doing so will never convert it again to a symlink
[01:18] <ajmitch> stgraber: so that's the case now, but I've seen plenty of suggestions to use chattr to stop it being overwritten
[01:19] <stgraber> ajmitch: yeah, this check was added in resolvconf when it was being prepared for 12.04
[01:19] <stgraber> ajmitch: the "old" resolvconf wasn't doing as many checks ;)
[01:19] <ajmitch> figures :)
[01:24] <slangasek> broder: why in the world would that have changed as part of a "memory-based scrollback stream backend"?
[01:28]  * kees looks around
[01:28]  * slangasek looks at kees
[01:28] <kees> I did upload vte yesterday...
[01:28] <slangasek> why did your upload break termcap handling for running processes? :)
[01:29] <kees> that part, I don't know
[01:29] <slangasek> well, broder asserts that "the new version of the library embeds the termcap instead of shipping it as a separate file"
[01:29] <slangasek> that doesn't seem like a trivial change to make accidentally :)
[01:29] <kees> unless that was is a result of a rebuild on a dep, I didn't make that change.
[01:30] <slangasek> ok
[01:32] <ajmitch> kees: does gnome-terminal use vte or vte3?
[01:32] <kees> oh yay, did vte fork now too?
[01:32] <ajmitch> looks like the change was in vte3, also uploaded yesterday
[01:32] <slangasek> oh sigh, of course
[01:32] <slangasek> yeah, that's why the changelog made no sense :P
[01:35] <kees> hrm, does this mean I need to get the memory-backed stuff into vte3 too?
[02:34] <broder> slangasek: pitti uploaded a new upstream release that i believe is to blame
[02:34] <slangasek> broder: yeah... I was looking at the wrong generation of libvte :)
[02:35] <broder> :)
[05:23] <kees> hrm, does nothing in oneiric provide the /usr/include/sys directory?
[05:27] <micahg> kees: apparently not
[05:27] <kees> wow.
[05:27]  * micahg doesn't see it in precise either FWIW
[05:27] <kees> that's a pretty bad regression. oh well, I guess no one uses /usr/include/syscall.h that much then?
[05:27] <kees> it's there in precise.
[05:27] <kees> drwxr-xr-x 2 root root 12288 Mar 22 16:34 /usr/include/sys/
[05:28] <kees> $ ls -la /usr/include/sys/syscall.h
[05:28] <kees> lrwxrwxrwx 1 root root 33 Mar 21 17:43 /usr/include/sys/syscall.h -> ../x86_64-linux-gnu/sys/syscall.h
[05:28] <jalcine> Is it safe to add icons into /usr/share/icons/hicolor ?
[05:28] <jalcine> Like via a package install?
[05:28] <micahg> kees: oh, that's there in oneiric, packages.ubuntu.com seems to be weird
[05:29] <kees> oh, hrm, I think it's done differently in oneiric... the compiler has the right paths. ah well
[05:44] <slangasek> kees: /usr/include/sys is only there for compatibility if you have the gcc biarch packages installed
[06:09] <pitti> Good morning
[06:10]  * pitti gratefully extends his thanks to infinity as well :)
[06:10] <pitti> broder: what's up? yes, new vte3 embeds that now
[06:22] <broder> pitti: sorry, didn't mean to ping you. the upgrade dropping the file caused problems for running gnome-terminal (if you opened a new terminal, which would have been in the old process)
[06:23] <pitti> broder: oh, I see; so just a temporary glitch
[06:24] <broder> yeah
[06:24] <vibhav>  
[06:25] <vibhav> oops
[06:31] <pitti> slangasek: acked bug 962124 FTR
[06:40] <slangasek> pitti: great, thanks :)
[07:47] <dholbach> good morning
[07:48] <pitti> hey dholbach
[07:48] <dholbach> hey pitti
[09:13] <shadeslayer> pitti: re bug 858970 : it's already fixed in precise ( the fix was incorporated into 6.1.4 )
[09:14] <shadeslayer> the problem is specific to version 6.1.3
[09:35] <pitti> shadeslayer: ah, can you please close the precise task then?
[09:35] <pitti> shadeslayer: that SRU was a bit confusing, it refers to two bugs, and the other looks like a synthetic meta-bug
[09:36] <shadeslayer> pitti: done, yeah, I thought that you had to open SRU bugs seprately to get packages SRU'd ... will take care next time :)
[09:37] <pitti> shadeslayer: no, please don't do that, it's confusing and actually detrimental to getting testing feedback
[09:37] <pitti> shadeslayer: the SRU policy page mentions this, too
[09:37] <pitti> shadeslayer: ok, thanks; will have another look at it
[09:37] <shadeslayer> thanks! sorry for the confusion
[09:40] <pitti> shadeslayer: accepted now, thanks
[09:40] <shadeslayer> \o/
[11:04] <dholbach> smoser, happy birthday!
[11:13] <seb128> ev, hey, those are the retracers dups from this week, most of the top 10 is whoopsie: http://pastebin.ubuntu.com/896289/
[11:13] <seb128> ev, if you could look at the ones listed there
[11:14] <ev> seb128: indeed, I'm on it. I had a chat with njpatel about it this morning and have a number of things to try an uncover the underlying memory corruption issue with.
[11:14] <seb128> ev, cool
[11:14] <seb128> ev, valgrind is your friend I would say ;-)
[11:15] <seb128> mvo, hey, I've assigned bug #938116 to you it's a quite frequent one as well
[11:15] <ev> indeed, I've been using it extensively, but it hasn't turned up the corruption on my local system.
[11:15] <ev> I've also worked with mudflap a bit, but it looks like you need to compile the world with it in order to not get a ton of false positives
[11:15] <mvo> seb128: its a segfault? in the python code?
[11:16] <mvo> seb128: oh, ok
[11:16] <seb128> mvo, no, in libapt-pkg.so.4.12
[11:16] <mvo> ta
[11:17] <seb128> mvo, thank *you* ;-)
[11:23] <hrw> hi
[11:23] <hrw> bug 962997 - can someone take a look?
[11:25] <MacSlow> seb128, didrocks: I'm just about to merge an approved fix for LP: #716458 to notify-osd and will do a release today too... so we get fixes for average bg-color and the multi-monitor issues.
[11:26] <MacSlow> seb128, didrocks: I hope you're ok with those for a new release.
[11:26] <seb128> MacSlow, great
[11:26] <seb128> MacSlow, yes
[11:37] <Laney> cjwatson: Just looking at bug #948848, what Conflicts are you proposing to add? Is it adding mono-gac << fixed-version to perl-base to ensure that the new version of mono-gac is unpacked early enough?
[12:20] <smoser> dholbach, thanks.
[12:31] <semiosis> SpamapS: ping?
[12:32] <alkisg> Hi mvo, sorry for the ping, ogra told me it'd be a good idea to notify you about https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/782953
[12:33] <alkisg> I just verified it, removed the cron jobs and software-center isn't aware of the new sources, even after running apt-get update, 1 hour later...
[12:37] <cjwatson> Laney: mono-gac/perl - correct, we need the new mono-gac to be at least unpacked before perl-base is unpacked so that when /usr/share/cli-common/runtimes.d/mono is invoked it isn't trying to use a Perl module that isn't currently in the configured state - this is the only way I know of to deal with this condition reliably
[12:40] <Laney> cjwatson: OK, got it. It seems odd that this situation arises; is using perl modules from pre* maintianer scripts just a bad idea?
[12:41] <Laney> i.e. what if we had actually been making use of that module?
[12:45] <cjwatson> Laney: well, you aren't pre-depending on perl, so you aren't entitled to expect perl to be configured, only perl-base, and File::Basename isn't in perl-base
[12:46] <cjwatson> Laney: but quite a few situations (config, sometimes prerm, postrm, triggers, basically anything that's asynchronous with respect to package state) can really only safely use Essential packages
[12:46] <cjwatson> regardless of (pre-)dependencies
[12:46] <cjwatson> hooks provided for use by other packages' maintainer scripts are really best advised to stick to Essential, IMO
[12:47] <Daviey> cjwatson: Ubuntu doesn't respect Essential, does it?
[12:49] <cjwatson> Daviey: ??!
[12:49] <Daviey> cjwatson: A package declaring itself essential, isn't necessarily published as Essential, is itt?
[12:49] <Laney> got it, the discussion about skew between perl-base and perl-modules skewed my mind also
[12:49] <cjwatson> Daviey: not true at all
[12:50] <cjwatson> Daviey: Priority and Section are overridden (also true in Debian); Essential is absolutely not
[12:53] <hrw> ok, another ftcbfs fixed - bug 963047
[13:04] <mvo> alkisg: cool, thanks
[13:05] <alkisg> You're welcome, if you could also have a look at https://bugs.launchpad.net/ubuntu/+source/dbconfig-common/+bug/962393 I'd appreciate it :)
[13:05] <alkisg> "...Maybe the problem is that software-center spawns debconf-communicate with the user id instead of as root"
[13:12] <smoser> cjwatson, around ?
[13:12] <smoser> i have a more clear question for you now regarding my grub issue. then i can dig some more,.
[13:13] <smoser> when we build the image files, we generally do so for a "full disk image" (with partition table).
[13:13] <smoser> where i was failing was where i was then trying to use the core.img file from inside that image when there was no partition table on the disk.
[13:14] <smoser> does that have any chance of working?
[13:17] <cjwatson> I think in principle it ought to but you're into much less well-tested code paths
[13:17] <cjwatson> you *should* be able to treat any device, disk or partition, as a filesystem
[13:45] <smoser> cjwatson, so if core.img is loaded
[13:45] <smoser> how does it know where modules and things are ?
[13:46] <cjwatson> smoser: it has a prefix baked into it
[13:46] <smoser> what does the prefix look like ?
[13:46] <smoser> (and when does it get baked in?)
[13:47] <cjwatson> depends on the platform; you can set it using the -p option to grub-mkimage, or sometimes grub-setup will add it depending on where you're installing the image to
[13:47] <cjwatson> the prefix is a full GRUB file name, as in http://www.gnu.org/software/grub/manual/grub.html#File-name-syntax - it should probably typically include a device
[13:47] <cjwatson> it ought to point to an equivalent of /boot/grub
[13:48] <smoser> cjwatson, well, i'm pretty sure my core.img gets built during dpkg install of a debootstrap
[13:48] <cjwatson> I'm pretty sure it doesn't
[13:48] <cjwatson> GRUB isn't in the base system
[13:48] <smoser> (then i'm pretty sure you're right)
[13:48] <smoser> oh
[13:48] <smoser> not debootstrap, sorry.
[13:48] <smoser> but installation in a similar manner. ie, in a chroot on a real disk that has no relavance to the end goal
[13:49] <cjwatson> so depends how (if) grub-install gets invoked within that environment, really.  you may have to call it by hand.
[13:49] <cjwatson> (or grub-mkimage / grub-setup manually, depending)
[13:49] <smoser> and later, we fake grub-probe and call grub-install.
[13:50] <cjwatson> use 'grub-install --debug' and see which mkimage/setup commands it's actually calling
[13:50] <smoser> but i didn't think grub-install touched core.img.
[13:50] <cjwatson> that's incorrect
[13:51] <cjwatson> it generates a new one
[13:51] <smoser> ah.
[13:51] <smoser> but not if --grub-setup=/bin/true
[13:52] <smoser> so that then at least makes sense to me. (i think).
[13:52] <cjwatson> why not if --grub-setup=/bin/true?  it's the grub-mkimage call that generates the core.img.
[13:52] <cjwatson> But certainly if you have --grub-setup=/bin/true it won't install it anywhere, and it's possible that the default prefix will be wrong
[13:53] <smoser> well, mhm..
[13:53] <smoser> i think i'm not explaining myself.
[13:53] <smoser> i have 1 core.img
[13:53] <smoser> and i was hoping that I could grub multiboot load that core.img
[13:53] <cjwatson> What I mean is that --grub-setup=/bin/true does not stop grub-install from generating a core.img.
[13:54] <smoser> but you're saying that that core.img has a prefix of some sort baked in.
[13:55] <smoser> so either that path is (hd0)/boot/grub/grub.cfg or (hd1,7)/boot/grub/grub.cfg
[13:56] <smoser> but i was hoping that the same core.img would work when it's view of the world was *either* (hd0,1)/boot/grub or (hd0)/boot/grub
[13:56] <cjwatson> Well, it can sometimes be device-independent as well, it depends on a few factors.  Can I go and write the foundations weekly report and then I'll get back to you?
[13:56] <cjwatson> 'cos I'm overdue.
[13:56] <smoser> no, cjwatson, you must do my bidding NOW
[13:56] <smoser> oh wait,
[13:56] <smoser> no, you can do that firts
[13:56] <smoser> thank you for your help.
[14:08] <smoser> cjwatson, when you do return, heres maybe a bit cleaner description
[14:08] <smoser> http://paste.ubuntu.com/896460/
[14:26] <dupondje> Did the ABI get bumped of openssl yesterday?
[14:27] <cjwatson> yes, though backward-compatibly
[14:29] <dupondje> Weird, cause freerdp nla auth is broken now. Tried a rebuild of the package, without changes, and it works ...
[14:33] <cjwatson> dupondje: is the source package 'freerdp'?
[14:34] <dupondje> Yes
[14:34] <cjwatson> It doesn't seem to do anything deeply horrible.  Let me poke around a bit ...
[14:34] <cjwatson> How do I reproduce the problem?
[14:35] <cjwatson> (Note, I don't have Windows)
[14:35] <dupondje> xfreerdp --sec nla <randomwindowsserver>
[14:35] <dupondje> :D
[14:35] <dupondje> but i'm doing some tests atm
[14:35] <cjwatson> I'll probably want to compare the binaries
[14:37] <cjwatson> smoser: I'll have a look at this image.  I probably need to meditate on it a bit
[14:37] <smoser> ok. thanks.
[14:37] <cjwatson> (ETA >1h for the download though)
[14:37] <smoser> cjwatson, you have canonistack credentials?
[14:37] <cjwatson> not quite sure why I'm only getting 50kb/s, that's even worse than usual
[14:37] <smoser> there, download is at 40M/s
[14:37] <Darxus> I just let update-manager do an automated upgrade, on Precise.  It failed, and now apt-get can't fix it:
[14:37] <Darxus> dpkg: error processing libfreetype6 (--configure): libfreetype6:amd64 2.4.4-2ubuntu1.2 cannot be configured because libfreetype6:i386 is in a different version (2.4.4-2ubuntu1.1)
[14:37] <cjwatson> I want it locally
[14:38] <cjwatson> it's worth waiting a while for downloads when it lets me work more quickly interactively once it's down
[14:38] <smoser> well, i can't help you there. but i can set up an instance for you if you'd like.
[14:38] <cjwatson> nah, no particular need I think
[14:38] <cjwatson> oh, heh, I have an sbuild-update running, that would explain it
[14:41] <cjwatson> dupondje: could you file a bug about this in the meantime?
[14:42] <dupondje> i'll do after some more tests :)
[14:42] <Darxus> Sorry, that was on Oneric that multiarch just broke hard.
[14:52] <dupondje> cjwatson: i'm unable to reproduce it now on another system.
[14:52] <dupondje> weird
[15:07] <jdstrand> pitti: hi! whenever you had a spare moment, would you mind deNEWing hamster-indicator (bug #686062)? I sponsored it, so I can't and it seems you are sympathetic to its inclusion :)
[15:08] <jdstrand> s/you had/you have/
[15:08] <jdstrand> pitti: it isn't urgent or anything
[15:29] <cjwatson> pitti: do you agree that I should add LC_IDENTIFICATION to Gunnar's list in https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/926207/comments/7 ?
[15:29] <cjwatson> (I went through the list in glibc)
[15:30] <pitti> cjwatson: hm, that's a good question -- there is no obvious "right" locale when you are using two at the same time
[15:30] <pitti> cjwatson: so if we want to be strict about the "preserve current behaviour", we'd need to
[15:30] <pitti> as we currently don't
[15:31] <cjwatson> as I read Gunnar's proposal it's just to flip the set round, so I think he just missed one
[15:32] <pitti> it feels a bit weird to set it explicitly, but I don't think it matters much either way
[15:32] <pitti> we can update accountsservice to do that as well
[15:32] <cjwatson> yes, it does, but meh, my gut feel has been overruled by fiat I think
[15:32] <cjwatson> and I don't care that much
[15:33] <jdstrand> mterry: hey. thanks for the MIR reviews. I wanted to mention to you that my focus for the last couple weeks has been almost entirely security reviews for MIRs, and it continues to be
[15:34] <mterry> jdstrand, :)  thanks
[15:56] <slangasek> SpamapS: I notice that you set the severity on bug #936667; do you care about giving ppa:jamesodhunt/upstart-testing a spin before we upload to the archive?
[16:17] <tkamppeter> infinity, hi
[16:22] <SpamapS> slangasek: I have that PPA enabled, but have not rebooted yet.. let me do that now.
[16:47] <jdstrand> tkamppeter: is is normal for me to now have 20 '/usr/lib/cups/notifier/dbus dbus://' processes?
[16:47] <jdstrand> tkamppeter: hi btw :)
[16:52] <slangasek> SpamapS: did you survive? :)
[16:53] <SpamapS> slangasek: still closing things down to be ready to reboot...
[16:53] <SpamapS> slangasek: < 5 min
[16:53] <slangasek> oh man
[16:53] <slangasek> :)
[16:53] <slangasek> here, let me throw you a critical bug in gnome-session to help speed things up
[16:56] <dholbach> jdstrand, I just reopened https://bugs.launchpad.net/ubuntu/+source/indicator-printers/+bug/959195
[16:56] <jdstrand> dholbach: ah, thanks :)
[16:56] <dholbach> jdstrand, ha! I even have more processes than you :)
[16:56] <jdstrand> hehe
[16:56] <jdstrand> quite a few more! :)
[16:57] <SpamapS> slangasek: looks good
[16:58] <SpamapS> slangasek: have we tried a cloud image yet?
[16:58] <SpamapS> slangasek: IIRC, cloud-init was a victim of the early job logging problems
[16:58] <slangasek> SpamapS: I don't know that anyone has; could you swing that as well?
[16:58] <SpamapS> slangasek: yes doing so now
[17:09] <tkamppeter> jdstrand, this is a known bug. It is fixed already. Do all updates and after that stop CUPS, "rm -r /etc/cups/subscriptions.conf /var/cache/cups/*", start CUPS again and the processes should go away.
[17:09] <jdstrand> tkamppeter: actually, so dholbach's comment, above ^
[17:09] <jdstrand> s/so/see/
[17:12] <jdstrand> tkamppeter: I did what you suggested and it didn't work
[17:14] <jdstrand> I commented in the bug
[17:16] <larsu> jdstrand, dholbach, hi
[17:16] <tkamppeter> jdstrand, dholbach, larsu will come up here and help you.
[17:16] <dholbach> I need to rush out now
[17:16] <dholbach> but I'm subscribed to the bug report and can do further testing if necessary
[17:17] <larsu> dholbach, cool, thanks
[17:17] <dholbach> see you later :)
[17:17] <tkamppeter> infinity, around?
[17:18] <infinity> tkamppeter: Yep.
[17:19] <larsu> jdstrand, argh, you're right, the commands I posted on that bug don't seem to work
[17:19] <SpamapS> slangasek: cloud instance boots fine w/ 1.5
[17:19] <slangasek> SpamapS: woot
[17:19] <SpamapS> slangasek: logging working fine too
[17:19] <htorque> larsu: they worked for me, what did i do wrong? :)
[17:19] <tkamppeter> infinity, it is about the p11-kit crash, bug 911436. It breaks CUPS and so very many people get Apport pop-ups when updating and there is CUPS or some printing package in the update, and these users probably also cannot print.
[17:20] <larsu> htorque, I don't know. They worked for me yesterday but not today
[17:20]  * larsu wonders where CUPS could cache subscriptions
[17:20] <SpamapS> slangasek: does upstart automatically re-open log files that get renamed?
[17:20] <tkamppeter> infinity, therefore I have raised the bug to "Critical" and added the rls-p-tracking tag. It has > 200 duplicates.
[17:20] <slangasek> SpamapS: dunno, ICMP REDIRECT jodh
[17:20] <SpamapS> jodh: does upstart automatically re-open log files that get renamed?
[17:21]  * SpamapS obeys the RFCs
[17:21] <infinity> tkamppeter: I'm aware.  Looking into it.
[17:21] <slangasek> tkamppeter: actually, I added the rls-p-tracking tag... please note that you shouldn't set this tag for other teams :)
[17:21] <jodh> SpamapS: yes.
[17:22] <SpamapS> jodh: *cool*
[17:22] <htorque> larsu: iirc, there was a second file like /etc/cups/subscriptions.0 - i removed that too.
[17:22] <SpamapS> jodh: I'm really excited about having job logging in upstart.. such a tiny thing but such a big win. :)
[17:23] <tkamppeter> larsu, htorque, jdstrand, I had to stop cups, then to remove /etc/cups/subscriptions.conf and /var/cache/cups/* and /var/cache/cup[s/rss/*. After that I have restarted cups.
[17:23] <larsu> htorque, nice, you're right. I wonder where that comes from (cups docs don't say anything about that)
[17:23] <jodh> SpamapS: tiny, but we've seen a few interesting corner cases ;)
[17:24] <SpamapS> jodh: whenever I hear "corner case" I think of The Blair Witch Project and "Mike" standing in the corner. ;)
[17:26] <slangasek> lool: hmph, mawk uploaded but no bug forwarded to Debian?  I had to wait for Ron to report it ;)
[17:27] <lool> slangasek: My changelog mentions a commit from collab-maint/mawk.git, isn't that from Debian?
[17:27] <slangasek> oh, ffs
[17:27] <slangasek> lool: that's not the package's repo, no
[17:28] <slangasek> lool: oh, also I was checking the wrong version of the package
[17:28] <larsu> jdstrand, please try again with the updated instructions I just posted
[17:28] <larsu> tkamppeter, ^^
[17:29] <lool> slangasek: I remember a weird situation around its Debian maintenance back then, but it's all fuzzy memories; I'm happy to forward remaining bits if any
[17:29] <slangasek> lool: apparently it's bryceh I need to be glaring at
[17:29] <lool> slangasek: this is http://paste.debian.net/160783/ e2e6d7ad490a7b19c562af5874a08a4168382b57
[17:29] <bryceh> slangasek, ?
[17:29] <slangasek> lool: yeah, don't worry about it, it's 1.3.3-16ubuntu3 I was referring to, I checked the sig on the wrong source package and came up with your name
[17:29] <tkamppeter> larsu, htorque, jdstrand, larsu's comment #4 should remove all these. Seems that cups has complex mechanisms to protect subscriptions against data loss.
[17:29] <slangasek> bryceh: patch not forwarded to Debian (where I'm the maintainer)
[17:30] <lool> Ok; /me paints himself with invisible paint
[17:31] <bryceh> slangasek, mind narrowing it down?
[17:31] <slangasek> bryceh: mawk
[17:31] <slangasek> LP: #955791
[17:32] <bryceh> slangasek, ah, the reporter claimed it to be fixed upstream, so I didn't think forwarding would be needed.
[17:32]  * slangasek snorts
[17:32] <slangasek> ok
[17:32] <bryceh> slangasek, also our mawk is way behind upstream
[17:32] <tkamppeter> larsu, should it not be "sudo rm -r /var/cache/cups/*", the empty /var/cache/cups/ directory is probably still needed by CUPS. Or will CUPS regenerate it?
[17:32] <slangasek> yeah, it's not "fixed upstream" because mawk doesn't have an upstream
[17:32] <larsu> tkamppeter, it regenerated it
[17:32] <slangasek> it has Thomas Dickey as a self-appointed upstream who throws tarballs over the fence
[17:32] <bryceh> slangasek, particularly, it has hardly changed since lucid (which is why the sru was so simple!)
[17:32] <slangasek> bryceh: but ok, understandable why you didn't forward in this case
[17:33] <tkamppeter> infinity, thanks.
[17:34] <bryceh> slangasek, https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/955791/comments/3
[17:34] <slangasek> bryceh: right, thanks :)
[17:34] <tkamppeter> infinity, a side effect is that some of the CUPS installation problems not caused by p11-kit got overlooked under the flooding.
[17:34] <semiosis> SpamapS: ping
[17:38] <SpamapS> semiosis: pong, sup?
[17:39] <semiosis> SpamapS: got a question re: glusterfs in precise... upstream just did a new patch release, 3.2.5 -> 3.2.6, and i'd like to put in a sync request for precise, but also want to be sure that the new version gets my upstart job merged in
[17:40] <semiosis> SpamapS: question is, do i need to do anything special beyond just filing a sync request bug?
[17:42] <SpamapS> semiosis: thats not a sync, thats a merge. :)
[17:43] <semiosis> true
[17:43] <semiosis> so my answer is file a merge bug then :)
[17:44] <SpamapS> semiosis: should be a pretty easy merge
[17:44] <semiosis> we did it once already for 3.2.5-1
[17:44] <SpamapS> semiosis: you should be able to submit your upstart job to debian maintainers for inclusion, then they can stay in sync
[17:45] <semiosis> i actually am co-maintainer of the debian package :)
[17:45] <SpamapS> semiosis: Ah, then you should be able to just put it in there!
[17:45] <semiosis> problem was (and i'm not 100% sure about this) that in my tests including the upstart job broke the package on debian
[17:45] <SpamapS> slangasek: dh_installinit should be fixed for shipping an upstart and an init file in Debian now, right?
[17:46] <semiosis> i'll go back and do the tests again
[17:46] <slangasek> SpamapS: not yet
[17:46] <SpamapS> oh
[17:46] <SpamapS> darn
[17:46] <semiosis> :D
[17:46] <semiosis> yeah...
[17:46] <semiosis> you can def. put the upstart job in the package, problems happen when you try to use that package
[17:46] <semiosis> iirc
[17:48] <semiosis> oh and another thing, even if upstart jobs were generally compatible with debian... this one in particular is specific to mountall, and it depends on wait-for-state, which afaik are ubuntu-specific additions to upstart
[17:48] <semiosis> is that right?
[17:49] <slangasek> semiosis: that's largely beside the point, as both mountall and wait-for-state will be landed in Debian as part of the process of making upstart usable for Debian packages
[17:49] <semiosis> slangasek: thats great to hear!  i hoped so
[17:50]  * semiosis looks forward to that day
[17:52] <semiosis> thanks SpamapS & slangasek for the info
[17:52] <SpamapS> semiosis: anyway, how about putting it in the package and doing some conditional logic to move it into place only when building for Ubuntu?
[17:54] <semiosis> SpamapS: thats a great idea, i never thought of that.  still pretty new to debian packaging.  i'll start working on that... could you point me toward any relevant docs/examples?  a package which does that would be a huge help, I like looking at source
[17:55] <semiosis> gotta go afk, bbiab.  thanks again!
[18:17] <PaoloRotolo> Hi all!
[18:52] <danel> anyone use this?
[18:52] <danel> If I'm writing helloworld.c
[18:52] <danel> and the main input argument is
[18:52] <danel> #include <stdio.h>
[18:52] <danel>    main()
[18:52] <danel>    {
[18:52] <danel>      printf( "Hello, world" );
[18:52] <danel>    }
[18:53] <danel> I open it with ./helloworld.c
[18:53] <danel> but compile it... with gcc -o helloworld.c?
[18:53] <jtaylor> this is the wrong channel for these questions, but its gcc helloworld.c -o helloworld; ./helloworld
[18:53] <danel> don't I need another tag for the output file name, in which case ./helloworld.c wouldn't open the file, since the input file is helloworld.c
[18:54] <danel> ok
[20:14] <Daviey> Pop Quiz:  If i really want postgres running during the installer, is running invoke-rc.d --force postgres start, evil.. from a postinst of a different package, that needs to use it?
[20:14] <Daviey> obv. ignoring policy.d
[20:15] <broder> yes. case in point: chroots. i never, ever, ever want any services running in one of my chroot, and a package shouldn't be able to override that want
[20:17] <azeem_> Daviey: why do you need to have it running?
[20:23] <slangasek> Daviey: if you insist on having it running, why call invoke-rc.d --force instead of calling the init script directly?
[20:24] <slangasek> though I think azeem_'s question may be the more fundamental one :)
[20:26] <Daviey> slangasek: I need to populate a database at d-i install time.
[20:26]  * slangasek nods
[20:27] <Daviey> slangasek: well sure, i thought that slightly cleaner than using /etc/init.d/foo start
[20:27] <slangasek> I guess there's no offline way to do that for postgres without using the db server?
[20:27] <Daviey> slangasek: NAFAIK
[20:28] <slangasek> yeah; I think calling the init script directly is cleaner than using --force on an interface that exists solely to give admins control over whether services are started
[20:28] <slangasek> (I'm surprised --force even exists, and wonder whose hare-brained idea that was)
[20:28] <Daviey> slangasek: the only other thing would be to have a pre-start job that checks some tmp file, to see if it is 'FIRST_RUN', and populdate at application start time.
[20:31] <Daviey> not sure i agree.. but i won't argue :)
[20:34] <Daviey> slangasek: --force implies retry, right?
[20:34] <Daviey> slangasek: do you think --force is /wrong/ to use, or just a taste thing?
[20:35] <slangasek> Daviey: --force is not part of the interface specified in Debian policy, so I think it's a) pointless and b) more likely to be rendered buggy in the future
[20:38] <Daviey> slangasek: Okay, thanks.. will use init.d.. thanks :)
[20:43] <azeem_> Daviey: interesting, what's the use case?  Can't you query a remote pgsql server?
[20:47] <Daviey> azeem_: It' an all in one, application needs a database.
[20:47] <Daviey> slangasek: is policy-rc.d return 101, the only metric that the user is in d-i?
[20:48] <slangasek> Daviey: I wouldn't say that it's an indicator at all, that's the same policy all of my chroots use :)
[20:49] <slangasek> I'm not sure what a better indicator would be
[20:49] <Daviey> slangasek: well, when i say metric.. i mean the closest to an indicator i have :(
[20:50] <slangasek> why do you need to check if it's really d-i?
[20:50] <slangasek> in broad strokes, what's the outcome you want here?  "Ensure postgres is always started, do our load, and if we started postgres, stop it again"?
[20:50] <Daviey> slangasek: I'd like to have slightly different behaviour on the cd, that i would if you apt-get'd.
[20:51] <slangasek> ah
[20:51] <slangasek> different how / why?
[20:51] <azeem_> can't you do that with debconf preseeding
[20:52] <Daviey> slangasek: dbcommon-config option to setup database.. i'd like to hide from the cd (as the option selected *owns* the box, and the choice is to run the database locally).. if you apt-get'd, i'd like to offer the user the choice.
[20:52] <Daviey> slangasek: yeah, i think preseeding is the best way
[20:52] <slangasek> yeah, I think so
[20:52] <Daviey> $package/dbconfig-true = True
[20:53] <Daviey> Okay, thanks for your help slangasek
[20:53] <slangasek> sure
[21:18] <shnatsel> I'm not sure if this is the proper place to ask this, but what writes /etc/adduser.conf ? I need to change DSHELL there and I can't find the relevant package to patch
[21:22] <dobey> shnatsel: dpkg -S $file tells you which packages own $file
[21:22] <shnatsel> dobey: it says none own it, that's the problem
[21:23] <shnatsel> dobey: I've also checked casper, just to be sure, but nothing there either
[21:24] <dobey> adduser: /usr/share/adduser/adduser.conf
[21:24] <dobey> shnatsel: /etc/adduser.conf seems to be old and no longer used
[21:25] <dobey> at least, i'm pretty sure i've upgraded my system since aug 2009
[21:25] <dobey> which is when that file was created
[21:25] <slangasek> no
[21:25] <dobey> or last modified rather
[21:25] <slangasek> /etc/adduser.conf is the config file which is created at install time by the adduser package, using /usr/share/adduser/adduser.conf as a template
[21:26] <slangasek> standard non-conffile handling
[21:26] <shnatsel> slangasek: oh, thanks a lot!
[21:26] <dobey> slangasek: then why does mine have a date of Aug 22 2009 on it?
[21:27] <shnatsel> dobey: "at install time"
[21:27] <shnatsel> dobey: and you've probably upgraded
[21:28] <shnatsel> I've just realized I should have grepped $(dpkg -L adduser) :/
[21:28] <shnatsel> thanks for your help!
[21:29] <slangasek> dobey: because config files for something like adduser don't change very often :)
[21:29] <slangasek> (in part because it's a pain to do it correctly)
[21:29] <dobey> slangasek: but i'd expect the dates on the two files to at least match (as in it just wrote the file out again from the updated package)
[21:30] <slangasek> not at all
[21:30] <slangasek> it's a *config* file; overwriting it on upgrade is exactly the wrong thing to do
[21:30] <dobey> except for all those times when i get debconf asking me to keep, replace, or merge the changes?
[21:31] <slangasek> I mean overwriting it silently is the wrong thing to do
[21:31] <slangasek> and there haven't been any changes upstream to this file lately
[21:32] <dobey> unless it's unchanged, in which case it's fine. but yeah, i agree it's hard to do right
[21:47] <SpamapS> hmm.. this is odd
[21:47] <SpamapS> I have a very minimal rules file..
[21:48] <SpamapS> with a package that has a single binary package..
[21:48] <SpamapS> and yet, dh_install is looking for files in debian/tmp ..
[21:48] <SpamapS> any ideas?
[21:48] <SpamapS> the files end up in debian/$packagename already because there is a single one
[21:49] <SpamapS> Ahh
[21:49] <SpamapS> because I have .install files
[21:49] <SpamapS> which I don't need anymore
[22:10] <bdmurray> slangasek: I'm looking at bug 274421 and while the gnome bug that would set the proxy to http://:8080 is fixed I wonder if that is enough
[22:18] <slangasek> bdmurray: I don't think individual packages should be expected to work around broken system proxy settings
[22:19] <bdmurray> slangasek: sure, I was thinking about fixing stored entries in debconf
[22:19] <slangasek> oh, is that getting set in debconf?
[22:20] <slangasek> bdmurray: feel free to mark it as a duplicate of bug #876298 then
[22:20] <bdmurray> comments 34 and 35 seem to indicate that
[22:20] <slangasek> ... although maybe that would be bad for LP :)
[22:20] <bdmurray> yeah, I think I'll close menting the proxy configuration tool changes
[22:21] <bdmurray> mentioning even
[22:25] <bdmurray> slangasek: also looking at bug 541595 no recent versions of apt seem to be implicated
[22:47] <jhojho> Sarvatt: the numbers do change quite a bit. look again (carefully)
[22:50] <Sarvatt> jhojho: i meant between 1.0.0 and 1.0.1 where the kernel didnt change when i said that, sorry
[22:50] <Sarvatt> http://paste.ubuntu.com/897098/
[22:51] <Sarvatt> aes hardly changes here so i attributed it to an outside source like it going through the kernel using CPU hardware acceleration for it, i dont know if thats actually the case :)
[22:52] <Sarvatt> was just a guess
[22:52] <jhojho> that's aesni.  not true here.
[22:52] <Sarvatt> i can't boot a lucid kernel on this machine to try it
[22:52] <jhojho> my processor does not have aesni
[22:53] <jhojho> so the use case of 64bit with no aesni is affected.
[22:53] <jhojho> and since the c version is faster, i would rather ubuntu use that instead.
[22:54] <jhojho> im fine with the asm version being slower for resistance to timing attacks but my point then is to just use the c version.