[00:13] skaet, around ? [00:34] slangasek: you need to restart gnome-terminal [00:34] the new version of the library embeds the termcap instead of shipping it as a separate file [00:34] rather, all of your terminals [00:39] smoser, just back from dinner, what's up? === dcp is now known as doctorpepper [01:12] I am impressed that the resolvconf postinst contains a detailed error about having an immutable resolv.conf file :) [01:15] there are probably quite a few blog posts telling people to make resolv.conf immutable to stop it being clobbered :) [01:15] indeed. it's the only way I could get n-m to behave itself. [01:15] ajmitch: no, the recommendation is to simply replace the symlink by a regular file [01:15] and it looks like resolvconf DTRT for my system, which I find very pleasing [01:16] ajmitch: doing so will never convert it again to a symlink [01:18] stgraber: so that's the case now, but I've seen plenty of suggestions to use chattr to stop it being overwritten [01:19] ajmitch: yeah, this check was added in resolvconf when it was being prepared for 12.04 [01:19] ajmitch: the "old" resolvconf wasn't doing as many checks ;) [01:19] figures :) [01:24] 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] I did upload vte yesterday... [01:28] why did your upload break termcap handling for running processes? :) [01:29] that part, I don't know [01:29] well, broder asserts that "the new version of the library embeds the termcap instead of shipping it as a separate file" [01:29] that doesn't seem like a trivial change to make accidentally :) [01:29] unless that was is a result of a rebuild on a dep, I didn't make that change. [01:30] ok [01:32] kees: does gnome-terminal use vte or vte3? [01:32] oh yay, did vte fork now too? [01:32] looks like the change was in vte3, also uploaded yesterday [01:32] oh sigh, of course [01:32] yeah, that's why the changelog made no sense :P [01:35] hrm, does this mean I need to get the memory-backed stuff into vte3 too? [02:34] slangasek: pitti uploaded a new upstream release that i believe is to blame [02:34] broder: yeah... I was looking at the wrong generation of libvte :) [02:35] :) === jalcine is now known as jalcine_ === jalcine_ is now known as jalcine [05:23] hrm, does nothing in oneiric provide the /usr/include/sys directory? [05:27] kees: apparently not [05:27] wow. [05:27] * micahg doesn't see it in precise either FWIW [05:27] that's a pretty bad regression. oh well, I guess no one uses /usr/include/syscall.h that much then? [05:27] it's there in precise. [05:27] drwxr-xr-x 2 root root 12288 Mar 22 16:34 /usr/include/sys/ [05:28] $ ls -la /usr/include/sys/syscall.h [05:28] lrwxrwxrwx 1 root root 33 Mar 21 17:43 /usr/include/sys/syscall.h -> ../x86_64-linux-gnu/sys/syscall.h [05:28] Is it safe to add icons into /usr/share/icons/hicolor ? [05:28] Like via a package install? [05:28] kees: oh, that's there in oneiric, packages.ubuntu.com seems to be weird [05:29] oh, hrm, I think it's done differently in oneiric... the compiler has the right paths. ah well [05:44] kees: /usr/include/sys is only there for compatibility if you have the gcc biarch packages installed [06:09] Good morning [06:10] * pitti gratefully extends his thanks to infinity as well :) [06:10] broder: what's up? yes, new vte3 embeds that now [06:22] 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] broder: oh, I see; so just a temporary glitch [06:24] yeah [06:24] [06:25] oops [06:31] slangasek: acked bug 962124 FTR [06:31] Launchpad bug 962124 in upstart (Ubuntu) "Feature Freeze Exception request for Upstart in Precise" [Wishlist,Triaged] https://launchpad.net/bugs/962124 [06:40] pitti: great, thanks :) [07:47] good morning [07:48] hey dholbach [07:48] hey pitti [09:13] pitti: re bug 858970 : it's already fixed in precise ( the fix was incorporated into 6.1.4 ) [09:13] Launchpad bug 858970 in virtuoso-opensource (Ubuntu Oneiric) "Virtuoso 6.1.3 cause nepomuk encoding error" [Undecided,New] https://launchpad.net/bugs/858970 [09:14] the problem is specific to version 6.1.3 [09:35] shadeslayer: ah, can you please close the precise task then? [09:35] shadeslayer: that SRU was a bit confusing, it refers to two bugs, and the other looks like a synthetic meta-bug [09:36] 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] shadeslayer: no, please don't do that, it's confusing and actually detrimental to getting testing feedback [09:37] shadeslayer: the SRU policy page mentions this, too [09:37] shadeslayer: ok, thanks; will have another look at it [09:37] thanks! sorry for the confusion [09:40] shadeslayer: accepted now, thanks [09:40] \o/ [11:04] smoser, happy birthday! [11:13] ev, hey, those are the retracers dups from this week, most of the top 10 is whoopsie: http://pastebin.ubuntu.com/896289/ [11:13] ev, if you could look at the ones listed there [11:14] 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] ev, cool [11:14] ev, valgrind is your friend I would say ;-) [11:15] mvo, hey, I've assigned bug #938116 to you it's a quite frequent one as well [11:15] Launchpad bug 938116 in apt (Ubuntu) "update-manager crashed with SIGSEGV in DescriptionList()" [High,Confirmed] https://launchpad.net/bugs/938116 [11:15] indeed, I've been using it extensively, but it hasn't turned up the corruption on my local system. [11:15] 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] seb128: its a segfault? in the python code? [11:16] seb128: oh, ok [11:16] mvo, no, in libapt-pkg.so.4.12 [11:16] ta [11:17] mvo, thank *you* ;-) === tomreyn_ is now known as tomreyn [11:23] hi [11:23] bug 962997 - can someone take a look? [11:23] Launchpad bug 962997 in debianutils (Ubuntu) "FTCBFS: Cross build calls wrong-arch strip " [Undecided,New] https://launchpad.net/bugs/962997 [11:25] 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] seb128, didrocks: I hope you're ok with those for a new release. [11:26] MacSlow, great [11:26] MacSlow, yes [11:37] 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? [11:37] Launchpad bug 948848 in perl (Ubuntu Precise) "cil packages fail to uninstall on lucid->precise upgrade due to prerm script use of perl-modules via /usr/share/cli-common/gac-package-remove -> /usr/share/cli-common/runtimes.d/mono (Can't locate File/Basename.pm in @INC)" [High,Triaged] https://launchpad.net/bugs/948848 [12:20] dholbach, thanks. === smb` is now known as smb === tkamppeter_ is now known as tkamppeter [12:31] SpamapS: ping? [12:32] 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:32] Launchpad bug 782953 in software-center (Ubuntu) "Software Center doesn't detect changes in sources until update-apt-xapian-index is ran by cron" [Medium,Triaged] [12:33] 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] 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] 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] i.e. what if we had actually been making use of that module? [12:45] 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 === _salem is now known as salem_ [12:46] 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] regardless of (pre-)dependencies [12:46] hooks provided for use by other packages' maintainer scripts are really best advised to stick to Essential, IMO [12:47] cjwatson: Ubuntu doesn't respect Essential, does it? [12:49] Daviey: ??! [12:49] cjwatson: A package declaring itself essential, isn't necessarily published as Essential, is itt? [12:49] got it, the discussion about skew between perl-base and perl-modules skewed my mind also [12:49] Daviey: not true at all [12:50] Daviey: Priority and Section are overridden (also true in Debian); Essential is absolutely not [12:53] ok, another ftcbfs fixed - bug 963047 [12:53] Launchpad bug 963047 in klibc (Ubuntu) "Fails to cross build" [Undecided,New] https://launchpad.net/bugs/963047 [13:04] alkisg: cool, thanks [13:05] 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] Launchpad bug 962393 in software-center (Ubuntu) "Installation loops in db-config-common when ran from software-center" [Undecided,New] [13:05] "...Maybe the problem is that software-center spawns debconf-communicate with the user id instead of as root" === MacSlow is now known as MacSlow|lunch [13:12] cjwatson, around ? [13:12] i have a more clear question for you now regarding my grub issue. then i can dig some more,. [13:13] when we build the image files, we generally do so for a "full disk image" (with partition table). [13:13] 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] does that have any chance of working? [13:17] I think in principle it ought to but you're into much less well-tested code paths [13:17] you *should* be able to treat any device, disk or partition, as a filesystem === dendro-afk is now known as dendrobates [13:45] cjwatson, so if core.img is loaded [13:45] how does it know where modules and things are ? [13:46] smoser: it has a prefix baked into it [13:46] what does the prefix look like ? [13:46] (and when does it get baked in?) [13:47] 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] 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] it ought to point to an equivalent of /boot/grub [13:48] cjwatson, well, i'm pretty sure my core.img gets built during dpkg install of a debootstrap [13:48] I'm pretty sure it doesn't [13:48] GRUB isn't in the base system [13:48] (then i'm pretty sure you're right) [13:48] oh [13:48] not debootstrap, sorry. [13:48] but installation in a similar manner. ie, in a chroot on a real disk that has no relavance to the end goal [13:49] so depends how (if) grub-install gets invoked within that environment, really. you may have to call it by hand. [13:49] (or grub-mkimage / grub-setup manually, depending) [13:49] and later, we fake grub-probe and call grub-install. [13:50] use 'grub-install --debug' and see which mkimage/setup commands it's actually calling [13:50] but i didn't think grub-install touched core.img. [13:50] that's incorrect [13:51] it generates a new one [13:51] ah. [13:51] but not if --grub-setup=/bin/true [13:52] so that then at least makes sense to me. (i think). [13:52] why not if --grub-setup=/bin/true? it's the grub-mkimage call that generates the core.img. [13:52] 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] well, mhm.. [13:53] i think i'm not explaining myself. [13:53] i have 1 core.img [13:53] and i was hoping that I could grub multiboot load that core.img [13:53] What I mean is that --grub-setup=/bin/true does not stop grub-install from generating a core.img. [13:54] but you're saying that that core.img has a prefix of some sort baked in. [13:55] so either that path is (hd0)/boot/grub/grub.cfg or (hd1,7)/boot/grub/grub.cfg [13:56] 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] 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] 'cos I'm overdue. [13:56] no, cjwatson, you must do my bidding NOW [13:56] oh wait, [13:56] no, you can do that firts [13:56] thank you for your help. [14:08] cjwatson, when you do return, heres maybe a bit cleaner description [14:08] http://paste.ubuntu.com/896460/ === MacSlow|lunch is now known as MacSlow [14:26] Did the ABI get bumped of openssl yesterday? [14:27] yes, though backward-compatibly [14:29] Weird, cause freerdp nla auth is broken now. Tried a rebuild of the package, without changes, and it works ... [14:33] dupondje: is the source package 'freerdp'? [14:34] Yes [14:34] It doesn't seem to do anything deeply horrible. Let me poke around a bit ... [14:34] How do I reproduce the problem? [14:35] (Note, I don't have Windows) [14:35] xfreerdp --sec nla [14:35] :D [14:35] but i'm doing some tests atm [14:35] I'll probably want to compare the binaries [14:37] smoser: I'll have a look at this image. I probably need to meditate on it a bit [14:37] ok. thanks. [14:37] (ETA >1h for the download though) [14:37] cjwatson, you have canonistack credentials? [14:37] not quite sure why I'm only getting 50kb/s, that's even worse than usual [14:37] there, download is at 40M/s [14:37] I just let update-manager do an automated upgrade, on Precise. It failed, and now apt-get can't fix it: [14:37] 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] I want it locally [14:38] it's worth waiting a while for downloads when it lets me work more quickly interactively once it's down [14:38] well, i can't help you there. but i can set up an instance for you if you'd like. [14:38] nah, no particular need I think [14:38] oh, heh, I have an sbuild-update running, that would explain it [14:41] dupondje: could you file a bug about this in the meantime? [14:42] i'll do after some more tests :) [14:42] Sorry, that was on Oneric that multiarch just broke hard. === jalcine is now known as jalcine_ [14:52] cjwatson: i'm unable to reproduce it now on another system. [14:52] weird [15:07] 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:07] Launchpad bug 686062 in Project Hamster "FFe: hamster-applet should have appindicator support" [Medium,New] https://launchpad.net/bugs/686062 [15:08] s/you had/you have/ [15:08] pitti: it isn't urgent or anything === bladernr_ is now known as bladernr_afk [15:29] 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] Launchpad bug 926207 in ubiquity (Ubuntu) "Set formats related LC_* variables when applicable instead of LC_MESSAGES, LC_CTYPE and LC_COLLATE" [Undecided,New] [15:29] (I went through the list in glibc) [15:30] cjwatson: hm, that's a good question -- there is no obvious "right" locale when you are using two at the same time [15:30] cjwatson: so if we want to be strict about the "preserve current behaviour", we'd need to [15:30] as we currently don't [15:31] as I read Gunnar's proposal it's just to flip the set round, so I think he just missed one [15:32] it feels a bit weird to set it explicitly, but I don't think it matters much either way [15:32] we can update accountsservice to do that as well [15:32] yes, it does, but meh, my gut feel has been overruled by fiat I think [15:32] and I don't care that much [15:33] 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] jdstrand, :) thanks === jalcine_ is now known as jalcine === deryck is now known as deryck[afk] [15:56] 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? [15:56] Launchpad bug 936667 in upstart (Ubuntu) "Upstart early job logging causes boot failure for systems with no initramfs (error is "No available ptys")" [High,Confirmed] https://launchpad.net/bugs/936667 [16:17] infinity, hi [16:22] slangasek: I have that PPA enabled, but have not rebooted yet.. let me do that now. [16:47] tkamppeter: is is normal for me to now have 20 '/usr/lib/cups/notifier/dbus dbus://' processes? [16:47] tkamppeter: hi btw :) [16:52] SpamapS: did you survive? :) [16:53] slangasek: still closing things down to be ready to reboot... [16:53] slangasek: < 5 min [16:53] oh man [16:53] :) [16:53] here, let me throw you a critical bug in gnome-session to help speed things up [16:56] jdstrand, I just reopened https://bugs.launchpad.net/ubuntu/+source/indicator-printers/+bug/959195 [16:56] Launchpad bug 959195 in indicator-printers (Ubuntu) "65 cups notifier processes running" [Undecided,Confirmed] [16:56] dholbach: ah, thanks :) [16:56] jdstrand, ha! I even have more processes than you :) [16:56] hehe [16:56] quite a few more! :) [16:57] slangasek: looks good [16:58] slangasek: have we tried a cloud image yet? [16:58] slangasek: IIRC, cloud-init was a victim of the early job logging problems [16:58] SpamapS: I don't know that anyone has; could you swing that as well? [16:58] slangasek: yes doing so now [17:09] 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] tkamppeter: actually, so dholbach's comment, above ^ [17:09] s/so/see/ [17:12] tkamppeter: I did what you suggested and it didn't work [17:14] I commented in the bug === larsu_ is now known as larsu [17:16] jdstrand, dholbach, hi [17:16] jdstrand, dholbach, larsu will come up here and help you. [17:16] I need to rush out now [17:16] but I'm subscribed to the bug report and can do further testing if necessary [17:17] dholbach, cool, thanks [17:17] see you later :) [17:17] infinity, around? [17:18] tkamppeter: Yep. [17:19] jdstrand, argh, you're right, the commands I posted on that bug don't seem to work [17:19] slangasek: cloud instance boots fine w/ 1.5 [17:19] SpamapS: woot [17:19] slangasek: logging working fine too [17:19] larsu: they worked for me, what did i do wrong? :) [17:19] 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] Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436 [17:20] htorque, I don't know. They worked for me yesterday but not today [17:20] * larsu wonders where CUPS could cache subscriptions [17:20] slangasek: does upstart automatically re-open log files that get renamed? [17:20] infinity, therefore I have raised the bug to "Critical" and added the rls-p-tracking tag. It has > 200 duplicates. [17:20] SpamapS: dunno, ICMP REDIRECT jodh [17:20] jodh: does upstart automatically re-open log files that get renamed? === jalcine is now known as jalcine_ [17:21] * SpamapS obeys the RFCs [17:21] tkamppeter: I'm aware. Looking into it. [17:21] tkamppeter: actually, I added the rls-p-tracking tag... please note that you shouldn't set this tag for other teams :) [17:21] SpamapS: yes. [17:22] jodh: *cool* [17:22] larsu: iirc, there was a second file like /etc/cups/subscriptions.0 - i removed that too. [17:22] jodh: I'm really excited about having job logging in upstart.. such a tiny thing but such a big win. :) [17:23] 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] htorque, nice, you're right. I wonder where that comes from (cups docs don't say anything about that) [17:23] SpamapS: tiny, but we've seen a few interesting corner cases ;) [17:24] jodh: whenever I hear "corner case" I think of The Blair Witch Project and "Mike" standing in the corner. ;) [17:26] lool: hmph, mawk uploaded but no bug forwarded to Debian? I had to wait for Ron to report it ;) [17:27] slangasek: My changelog mentions a commit from collab-maint/mawk.git, isn't that from Debian? [17:27] oh, ffs [17:27] lool: that's not the package's repo, no [17:28] lool: oh, also I was checking the wrong version of the package [17:28] jdstrand, please try again with the updated instructions I just posted [17:28] tkamppeter, ^^ [17:29] 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] lool: apparently it's bryceh I need to be glaring at [17:29] slangasek: this is http://paste.debian.net/160783/ e2e6d7ad490a7b19c562af5874a08a4168382b57 [17:29] slangasek, ? [17:29] 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] 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] bryceh: patch not forwarded to Debian (where I'm the maintainer) [17:30] Ok; /me paints himself with invisible paint [17:31] slangasek, mind narrowing it down? [17:31] bryceh: mawk [17:31] LP: #955791 [17:32] 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] ok [17:32] slangasek, also our mawk is way behind upstream [17:32] 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] yeah, it's not "fixed upstream" because mawk doesn't have an upstream [17:32] tkamppeter, it regenerated it [17:32] it has Thomas Dickey as a self-appointed upstream who throws tarballs over the fence [17:32] slangasek, particularly, it has hardly changed since lucid (which is why the sru was so simple!) [17:32] bryceh: but ok, understandable why you didn't forward in this case [17:33] infinity, thanks. [17:34] slangasek, https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/955791/comments/3 [17:34] Launchpad bug 955791 in mawk (Ubuntu Oneiric) "Source and destination overlap in memcpy" [Undecided,In progress] [17:34] bryceh: right, thanks :) [17:34] infinity, a side effect is that some of the CUPS installation problems not caused by p11-kit got overlooked under the flooding. [17:34] SpamapS: ping [17:38] semiosis: pong, sup? [17:39] 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] SpamapS: question is, do i need to do anything special beyond just filing a sync request bug? [17:42] semiosis: thats not a sync, thats a merge. :) [17:43] true [17:43] so my answer is file a merge bug then :) [17:44] semiosis: should be a pretty easy merge [17:44] we did it once already for 3.2.5-1 [17:44] semiosis: you should be able to submit your upstart job to debian maintainers for inclusion, then they can stay in sync [17:45] i actually am co-maintainer of the debian package :) [17:45] semiosis: Ah, then you should be able to just put it in there! [17:45] 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] slangasek: dh_installinit should be fixed for shipping an upstart and an init file in Debian now, right? [17:46] i'll go back and do the tests again [17:46] SpamapS: not yet [17:46] oh [17:46] darn [17:46] :D [17:46] yeah... [17:46] you can def. put the upstart job in the package, problems happen when you try to use that package [17:46] iirc [17:48] 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] is that right? [17:49] 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] slangasek: thats great to hear! i hoped so [17:50] * semiosis looks forward to that day === deryck[afk] is now known as deryck [17:52] thanks SpamapS & slangasek for the info [17:52] 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] 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] gotta go afk, bbiab. thanks again! [18:17] Hi all! [18:52] anyone use this? [18:52] If I'm writing helloworld.c [18:52] and the main input argument is [18:52] #include [18:52] main() [18:52] { [18:52] printf( "Hello, world" ); [18:52] } [18:53] I open it with ./helloworld.c [18:53] but compile it... with gcc -o helloworld.c? [18:53] this is the wrong channel for these questions, but its gcc helloworld.c -o helloworld; ./helloworld [18:53] 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] ok === yofel_ is now known as yofel === jalcine_ is now known as jalcine === dendrobates is now known as dendro-afk === Guest35182 is now known as jalcine === jalcine is now known as Guest31394 [20:14] 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] obv. ignoring policy.d [20:15] 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] Daviey: why do you need to have it running? === Guest31394 is now known as jalcine [20:23] Daviey: if you insist on having it running, why call invoke-rc.d --force instead of calling the init script directly? [20:24] though I think azeem_'s question may be the more fundamental one :) [20:26] slangasek: I need to populate a database at d-i install time. [20:26] * slangasek nods [20:27] slangasek: well sure, i thought that slightly cleaner than using /etc/init.d/foo start [20:27] I guess there's no offline way to do that for postgres without using the db server? [20:27] slangasek: NAFAIK [20:28] 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] (I'm surprised --force even exists, and wonder whose hare-brained idea that was) [20:28] 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] not sure i agree.. but i won't argue :) [20:34] slangasek: --force implies retry, right? [20:34] slangasek: do you think --force is /wrong/ to use, or just a taste thing? [20:35] 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] slangasek: Okay, thanks.. will use init.d.. thanks :) === jalcine is now known as jalcine_ === jalcine_ is now known as jalcine [20:43] Daviey: interesting, what's the use case? Can't you query a remote pgsql server? [20:47] azeem_: It' an all in one, application needs a database. [20:47] slangasek: is policy-rc.d return 101, the only metric that the user is in d-i? [20:48] Daviey: I wouldn't say that it's an indicator at all, that's the same policy all of my chroots use :) [20:49] I'm not sure what a better indicator would be [20:49] slangasek: well, when i say metric.. i mean the closest to an indicator i have :( [20:50] why do you need to check if it's really d-i? [20:50] 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] slangasek: I'd like to have slightly different behaviour on the cd, that i would if you apt-get'd. [20:51] ah [20:51] different how / why? [20:51] can't you do that with debconf preseeding [20:52] 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] slangasek: yeah, i think preseeding is the best way [20:52] yeah, I think so [20:52] $package/dbconfig-true = True [20:53] Okay, thanks for your help slangasek [20:53] sure [21:18] 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] shnatsel: dpkg -S $file tells you which packages own $file [21:22] dobey: it says none own it, that's the problem [21:23] dobey: I've also checked casper, just to be sure, but nothing there either [21:24] adduser: /usr/share/adduser/adduser.conf [21:24] shnatsel: /etc/adduser.conf seems to be old and no longer used [21:25] at least, i'm pretty sure i've upgraded my system since aug 2009 [21:25] which is when that file was created [21:25] no [21:25] or last modified rather [21:25] /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] standard non-conffile handling [21:26] slangasek: oh, thanks a lot! [21:26]