[04:18] <pitti> Good morning
[04:18] <pitti> RAOF: thanks for the psql reviews!
[04:19] <RAOF> pitti: No problem!
[04:19] <pitti> RAOF: could you review the lucid one, too?
[04:19] <RAOF> Hm, did I not do that one too?
[04:20] <pitti> it's still in the queue, and I didn't get a message for it
[04:24] <RAOF> Ah. That's because sru-review barfed on it last time. Done!
[04:30] <pitti> RAOF: cheers! barfed how?
[04:31] <RAOF> pitti: I think it was a timeout. My internet is being a bit wonky.
[04:31] <pitti> I'll run the test suites with the proposed .debs today
[07:00] <dholbach> good morning
[08:23] <xnox> pitti: can I quickly poke you about libudev? i'm looking to add nomatch filters to the  udev_monitor. Similar to how filter_subsystem_list and filter_tag_list, expect that i need to add exclude / nomatch (similar to how nomatch works with enumerate functions).
[08:24] <xnox> this is for bug #1234743
[08:24] <pitti> xnox: you can poke me, but as I said last week I never did anything with netlink filters, so I'm afraid I have zero experience there :/
[08:25] <pitti> xnox: besides, libudev is the wrong place for that
[08:25] <pitti> xnox: what we want is to apply that filter in udev daemon, on the "kernel" side
[08:25] <pitti> they shouldn't even appear on the "udev" netlink side
[08:25] <pitti> (IMHO)
[08:25] <xnox> pitti: the way I see it, is that udevd will add a filter, but it's using libudev api throughout. So libudev needs "nofilter" functions that one can set excludes, which are applied to the requested monitor.
[08:26] <xnox> and udev netlink side is generated by udevd listening to kernel events?
[08:26] <pitti> xnox: yes, it has a private libudev API for that
[08:26]  * xnox thought that if I filter kernel netlink in udevd, nothing will appear on the udev netlink.
[08:26] <xnox> or is that not correct?
[08:26] <pitti> xnox: yes; udevd listens to the "kernel" originated uevents, applies its rules etc., adds the extra properties, tags, etc from them, and re-sends them as "udev" uevent source
[08:27] <pitti> and usually clients only listen to the "udev" source
[08:27] <xnox> i was hoping to record and replay the stream of udev events, with/without my filter to make sure that my filter is correct.
[08:27] <pitti> that's the difference between udevadm monitor --udev and --kernel
[08:27] <xnox> ok. so i understood that correct.
[08:27] <pitti> xnox: so it seems easiest to filter out that one event in udevd
[08:27] <pitti> without making any public API changes
[08:27] <pitti> (OMG, please let's not change any API/ABI for such a hilarious hack)
[08:27] <xnox> =)
[08:27] <xnox> ok.
[08:28] <xnox> it's just i don't want udev to wake up at all for those, hence the netlink filter.
[08:28] <pitti> xnox: exactly
[08:28] <pitti> xnox: hence applying that filter in udevd on the kernel side
[08:28] <pitti> instead of on the udev side, where udevd would wake up all the time
[08:28] <xnox> pitti: ack.
[08:29] <xnox> pitti: looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743/comments/7  i think that's variables as exported by upstart bridge.
[08:30] <xnox> pitti: but in uevent/udev terms are those properties?
[08:30] <pitti> xnox: yes, they are
[08:30] <pitti> xnox: attributes are in sysfs, like in /sys/devices/platform/omapfb/<fileX>
[08:30] <xnox> i think I just want to ignore any VSYNC.
[08:30] <xnox> change events.
[08:31] <pitti> xnox: properties are stuff that udev rules can add, and some come from the kernel or udevd itself (DRIVER, ACTION, USEC_INITALIZED, and so on)
[08:34] <pitti> xnox: hm, I guess you need to add an accessor to udev_monitor->sock to src/libudev/libudev-private.h
[08:35] <pitti> xnox: perhaps it's easiest indeed to add the hack to src/libudev/libudev-monitor.c indeed, to udev_monitor_new_from_netlink_fd() if name == "kernel"
[08:35] <xnox> well there is udev_monitor_filter_update() which applies the filters already
[08:35] <pitti> xnox: there you have the sock and can can attach the extra filter
[08:35] <xnox> (filter by subsystem or tag)
[08:36] <xnox> if i access and modify filter directely any calls to filter_update() will wipe mine. (i think, unless i'm careful to use a different magic #)
[08:36] <pitti> xnox: ah yes, that's fine; udev_monitor_enable_receiving() calls that, and is called by udevd at the beginning
[08:36] <xnox> so i was thinking, if I am to add api-less hack that would be there.
[08:36] <pitti> xnox: agreed
[08:36] <xnox> ack.
[08:37] <xnox> pitti: can udevmock reply kernel src uevents?
[08:38] <pitti> xnox: it doesn't actually make that distinction between kernel/udev
[08:38] <pitti> xnox: but I doubt that you currently can run udevd itself against umockdev, as all of its netlink filter operations just won't work on our fake unix socket
[08:40] <xnox> i see.
[08:40] <pitti> xnox: for testing, I propose you take any existing driver on your system, where you can trigger a kernel-level uevent by writing into /sys/.../udevent
[08:41] <pitti> xnox: and write your code with some other device name/property
[08:41] <pitti> xnox: s/udevent/uevent, of course
[08:41] <pitti> xnox: then, if filtering that out works, it should be a mere string replacement in your hack, and just one verification on maguro (or wherever that happens)
[08:43] <pitti> xnox: e. g.
[08:43] <pitti> $ echo change | sudo tee /sys/class/misc/uinput/uevent
[08:43] <pitti> $ udevadm monitor -e --kernel
[08:43] <pitti> [...]
[08:43] <pitti> KERNEL[16115.645262] change   /devices/virtual/misc/uinput (misc)
[08:43] <pitti> ACTION=change
[08:43] <pitti> [...]
[08:43] <pitti> (you need to start the monitor before, of course)
[08:48] <xnox> pitti: right, can i add attributes to it? or shall i write something in c then to emit proper uevent?
[08:49] <pitti> xnox: no, you can't change the set of attributes of a kobject, that's defined by the driver (only)
[08:49] <xnox> ah.
[08:50] <pitti> xnox: the /uevent attribute shows the kernel-defined properties
[08:50] <pitti> xnox: but I don't know whether you can "inject" them with that method
[08:51] <pitti> the naive approach with "echo -e 'change\nFOO=bar'" doesn't work
[08:51] <pitti> xnox: so perhaps test with MINOR= or something
[09:10] <mpt> mvo! Could you please review <https://code.launchpad.net/~brunonova/software-properties/update-apt-on-exit/+merge/190498>? It's a grand total of two lines change.
[09:19] <xnox> pitti: is systemd-udev statically linked againt libudev? cause i don't think i want to change the behaviour of libudev1 et.al.
[09:20] <pitti> xnox: yes, it is; it builds a libudev-private.la durig package build and links udevd, udevadm etc. against that
[09:20] <pitti> so that the private symbols don't appear in the public lib
[09:20] <pitti> xnox: actually I think with above approach you will
[09:21] <pitti> xnox: but that's ok; any other program which uses libudev to listen for kernel events will then also have these filtered out
[09:27] <xnox> pitti: i'm now thinking to cheat.
[09:28] <pitti> xnox: you are considering making the change in udevd.c only? then you'll need an accessor for "int sock" in libudev-private.h
[09:29] <xnox> pitti: i'd like to invert the meaning of lilter tag - from include only this tag, to drop anything tagged. Then add udev rule to tag omapfb device with tag "ignoreme" and then add udevd filter tag "ignoreme"
[09:29] <xnox> overall that should be quite small and obvious, yet horribly breaking all existing conventions.
[09:30] <xnox> unless that would break udevadm monitor =/
[09:30] <xnox> hmm... or I shall copy & paste.
[09:33] <tvoss> jodh, ping
[09:34] <jodh> tvoss: hi
[09:42] <pitti> xnox: re (sorry, was OTP)
[09:42] <pitti> xnox: "invert meaning of filter tag" sounds quite intrusive?
[09:42] <xnox> pitti: well, i think i came up with something even better now.
[09:42] <xnox> pitti: let me hack a bit, and I'll ping you for code review.
[09:43] <pitti> ack
[09:54] <tvoss> doko, mind pinging me the link to your fix for the pretty printer python scripts again?
[12:22] <kubuntu83> Greetings, everyone. Am I understanding correctly that, in Saucy, the appmenu-gtk* packages were superseded by packages which no longer work outside of Unity (particularly KDE)?
[12:23] <xnox> kubuntu83: define "no longer work" they do work with gtk2 and gtk3 panels (applets), indeed so far there is no appmenu-ng port to qt4/plasma. It does work in qt5/declarative for example.
[12:24] <xnox> no port to qt5/framework5 yet either, I think.
[12:28] <kubuntu83> xnox: Gtk2/3 apps are no longer exporting their menus under KDE -- not to KRunner, KWin, or Plasma (all of which are picking up Qt menus just fine).
[12:31] <xnox> kubuntu83: correct.
[12:32]  * xnox ponders if we should disable menuproxy for gtk under kde then.
[12:43] <kubuntu83> xnox: Any idea which packages I would need to downgrade/pin to get the old functionality back, or if that's even possible?
[12:46] <xnox> kubuntu83: i don't think it will be possible, as it's abi transition, you'd have to downgrade all the gtk apps to get them linked against older indicators, which in turn will bring a large can of worms and you end up running quantal.
[12:47] <cjwatson> barry: Er, WTF - running the system-image autopkgtests, they chmodded my /tmp to 2700
[12:47] <xnox> kubuntu83: i think it should be possible to export a varible / change gsettings such that the menubar is back within the app and clickable, but it will not export the menus anywhere either.
[12:49] <cjwatson> barry: I uploaded http://paste.ubuntu.com/6240379/ to make the autopkgtests pass again; Vcs-Bzr points to lp:~ubuntu-system-image/ubuntu-system-image/client, but that doesn't contain the packaging, so I didn't know if there was anywhere I could commit this
[12:51] <kubuntu83> xnox: It's already showing up within the app, so I guess it could be worse.
[12:56] <xnox> kubuntu83: oh, that's ok then.
[12:56] <xnox> kubuntu83: i don't think you can get better than that.
[12:56] <xnox> (i guess it checks and finds out there is no dbus service listening to receive the -ng menus, and gives up)
[12:56] <kubuntu83> :'(
[12:57] <kubuntu83> Sorry to bitch and moan. I just spent the weekend porting packages to Saucy, only to run into an issue that will probably keep me from using it.
[12:59] <barry> cjwatson: yikes, that's not good.  yeah, i'll fix that
[13:02] <kubuntu83> xnox: Sorry to keep bugging you, but do you have any idea who I should be petitioning to get a Qt4/Plasma port of appmenu-ng?
[13:03] <xnox> kubuntu83: can you write code? if not find a volunteer who wants to write it. it should be fairly straight forward from gtk port.
[13:04] <xnox> kubuntu83: it simply needs to find somebody with time to volunteer and contribute the qt4 port. no petitioning is required.
[13:04] <kubuntu83> xnox: Right, I was using "petitioning" figuratively. ;)
[13:05] <doko> mvo, apt ping
[13:06] <xnox> kubuntu83: ok =) i see.
[13:06] <kubuntu83> xnox: By the way, you said I'd end up running Quantal if I tried downgrading the relevant packages, but... Everything (appmenu-wise) was working fine in Raring. Not sure if that's relevant. I assumed appmenu-ng is new to Saucy, right?
[13:07] <xnox> kubuntu83: oh was it. can't remember if it was quantal or raring where the -ng appmenu was introduced, i might be wrong.
[13:07] <mvo> doko: apt pong (but in a meeting, so expect some delay in asnwering)
[13:11] <kubuntu83> xnox: Alright, well... Thanks for filling me in. Peace.
[13:40] <knocte> how can I know who is in charge of some ubuntu package?
[13:42] <mdeslaur> knocte: Ubuntu doesn't have maintainers like Debian does. Looking at the changelog may give you an indication of who usually updates it though.
[13:42] <xnox> pitti: here is my work in progress (sorry for so late, been pinged to do other stuff) http://paste.ubuntu.com/6240591/
[13:42] <mdeslaur> knocte: any package in particular?
[13:42] <knocte> mdeslaur: libgstreamer packages
[13:43] <xnox> pitti: completely untested at the moment, so the idea is that netlink filter will drop packets from devices tagged "ignore". Reusing existing netfilter logic used to _match only_ tag.
[13:43] <pitti> xnox: heh, fun; ages ago, udev actually had something like that already, but it was removed because nobody used it and it was considered a bad workaround for a kernel bug :)
[13:43] <pitti> xnox: right
[13:44] <mdeslaur> knocte: doesn't look like anyone in particular takes care of them. Best bet is to file a bug if you have an issue, or want to submit a debdiff to fix something.
[13:45] <knocte> I'll file a bug, thanks
[13:45] <pitti> xnox: so, I don't understand the logic in the first block (how does adding to udev_monitor->filter_tag_list suddenly make it a "no match" tag?)
[13:45] <xnox> pitti: well it still does have "nomatch" type of filters in the enumerate, just not in the monitors.
[13:45] <pitti> xnox: ah, filter_tag_list is actually that "filter out these tags" already?
[13:46] <xnox> pitti: so the difference is for all tags, compare lower/upper part of tags and if matched.....
[13:46] <xnox> ... previously jump after drop packet
[13:46] <xnox> now branch: for "match-only tagged" (old / normal) jump after drop packet; for "nomatch" jump _to_ drop packet;
[13:46] <pitti> (no idea how that code/bpf is working)
[13:48] <xnox> pitti: BPF_JMP -> jump instructions, BPF_JEQ if equal to BPF_K constant value. If true instruction location, false instruction location.
[13:48] <pitti> xnox: so, if that works, it looks fine to me; unintrusive (API-wise) and shoudl avoid all wakeups
[13:48] <xnox> pitti: depending on the value of the tag, i jump one instruction less or not.
[13:48] <xnox> (or jump past the drop or not)
[13:49] <pitti> xnox: what does the "nomatch" string value do?
[13:49] <xnox> i think it will drop everything if no tags matched at the moment. let me think about it.
[13:49] <pitti> list_entry in the top corresponds to udev_monitor->filter_tag_list?
[13:49] <xnox> pitti: at the moment it can be any. _add_match_filter results in value NULL, and at the moment i simply use ! NULL to consider that it's nomatch branch.
[13:49] <pitti> otherwise it would break the default behaviour
[13:50] <xnox> pitti: so "nomatch" can be any string.
[13:50] <pitti> ah, ok
[13:50] <xnox> pitti: i guess instead of if (udev_list_entry_get_value(list_entry) == NULL)  I could do explicit string comparison.
[13:50] <pitti> the code uses filter_tag_list for positive matches, though
[13:51] <pitti> so if you change that list to mean "filter out" tags, how does that not break current behaviour?
[13:51] <xnox> pitti: i'm trying to conditionalise it.
[13:51] <xnox> pitti: by adjusting the actions when tags are matched. I guess i'm wrong now.
[13:51] <pitti> xnox: ah, that's just a check if it works at all, not yet meant to be fully working
[13:52] <xnox> pitti: since untagged by default would be now dropped, if there is only one nomatch tag.........
[13:52]  * xnox needs to think about it.
[13:53] <xnox> maybe i need a global flag / option then (not on per tag level) if the filter_tags are to include-only or exclude-only
[14:01] <pitti> xnox: hm, that sounds a bit dangerous as well
[14:02] <xnox> pitti: well, the api is private and not public, and we only expose / use it in one place in udevd, such that if behaviour for udevd is correct and the libudev behaviour is un-changed we should be ok.
[14:06] <barry> jdstrand: ping
[14:21] <jdstrand> barry: hi!
[14:22] <barry> jdstrand: hi!  could you sanity check: https://bugs.launchpad.net/ubuntu/+source/system-image/+bug/1235975/comments/5
[14:27] <jdstrand> barry: I think that is all reasonable, but might mention this-- now that /var/log/system-image and /var/lib/system-image will be created with the correct permissions, why not move the 'correct bad permissions' code into postinst conditional on an upgrade to the release (or past) the one that fixes the issue?
[14:28] <jdstrand> barry: furthermore, shouldn't the debian packaging be creating those directories in the first place? that way they can be cleaned up on uninstall
[14:29] <jdstrand> (perhaps the debian packaging is already doing that-- it wasn't clear from the comment)
[14:30] <barry> jdstrand: it's not, but i do think it makes sense to have the packaging change any existing directories, and leave the s-i code to *create* files and directories correctly.  that would leave just the logfile itself and the random temp subdir.
[14:30] <barry> jdstrand: of course, if someone changes the config file to point to different locations, their on their own
[14:31] <barry> *they're
[14:31] <jdstrand> barry: yes. I think that is reasonable in this case
[14:32] <barry> jdstrand: i think i will open a new bug for this and try to squeeze in a 1.9.1.  if you want to review the branches (yes, two of them) let me know
[14:32] <jdstrand> ok
[14:37] <cjwatson> barry: could you look at the current system-image autopkgtest failures?  Linked from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#system-image (the public link probably isn't up to date yet; the private link requires batuan VPN access)
[14:38] <barry> cjwatson: lool is pinging me on #ubuntu-touch, probably about the same thing ;)
[14:38] <cjwatson> yep
[14:53] <barry> jdstrand: LP: #1240105
[15:42] <jdstrand> barry: ack
[15:42] <infinity> sarnold: *pokity poke*
[16:07] <jtaylor> stgraber: re bug 1236957, python3-pyparsing is provided by pyparsing, a different source package
[16:11] <stgraber> jtaylor: oh, indeed, so source only removal then, good
[16:11] <stgraber> well, no, source and one binary
[16:12] <stgraber> jtaylor: done
[16:13] <jtaylor> thx
[16:56] <PeterCassetta> Is this the right place to ask about getting certain universe packages updated?
[17:05] <sarnold> infinity: sorry, I've not yet started 1220434 for curtin, but if it's any consolation I took my dog for a good long walk in the wonderful weather on yesterday's day off :)
[17:06] <xnox> PeterCassetta: usually, just ask whatever you want to ask =)))) then people can respond and/or redirect.
[17:06] <infinity> sarnold: We're cutting it pretty dangerously close to release.
[17:06] <xnox> PeterCassetta: nobody asks to ask a question on irc ;-)
[17:07] <PeterCassetta> xnox, okay, cool.
[17:13] <sarnold> infinity: indeed :(
[17:14] <PeterCassetta> There's a few applications I use fairly often which are pretty out of date.
[17:15] <PeterCassetta> OpenTTD in the software center is 1.2.3, but the latest stable version is 1.3.2.
[17:16] <PeterCassetta> Blender is also two versions behind (soon to be three), at 2.66a.
[17:16] <PeterCassetta> The latest official stable version is 2.68a.
[17:17] <cjwatson> Realistically, the best way to get that kind of thing updated is to get the Debian maintainer to update their packages, and then we'll sync/merge them into whatever the current Ubuntu development release is at the time
[17:17] <cjwatson> And maybe then backport to stable releases
[17:17] <cjwatson> In saucy, openttd is 1.3.1, blender is still 2.66a
[17:17] <cjwatson> But we don't update stable releases with new upstream versions, generally - that's what the various -backports repositories are for
[17:18] <cjwatson> https://wiki.ubuntu.com/UbuntuBackports
[17:18] <cjwatson> blender is 2.68a in saucy-proposed, but unfortunately it fails to build everywhere
[17:18] <cjwatson> https://launchpad.net/ubuntu/+source/blender/2.68a-3
[17:19] <cjwatson> So that needs to be fixed
[17:19] <cjwatson> Looks like it may perhaps be blocked on the libav 9 transition, which will be happening early in the next release cycle
[17:19] <cjwatson> Might need extra work to be backportable then, though
[17:20] <PeterCassetta> cjwatson, are universe packages generally not updated after an Ubuntu release comes out?
[17:20] <cjwatson> No
[17:20] <cjwatson> Except sometimes in -backports
[17:24] <PeterCassetta> cjwatson, just to be clear: If, say, OpenTTD is backported from saucy, would I then be able to install it on ringtail?
[17:25] <cjwatson> PeterCassetta: I don't recall how it shows up in software-center, but worst case it would be installable on raring with "apt-get -t raring-backports install ..."
[17:28] <PeterCassetta> cjwatson, okay, one last question: When asking for a backport from, say, saucy, would I report it in the project "saucy-backports"?
[17:29] <cjwatson> No, report it on the target (e.g. raring-backports)
[17:29] <PeterCassetta> cjwatson: Okay, cool, thanks for the help. :)
[17:29] <rbasak> PeterCassetta: full explanation here: https://wiki.ubuntu.com/UbuntuBackports#Requesting_a_Backport
[17:29] <cjwatson> np
[17:58] <Bluefoxicy> bah.  I can't figure out how to get dpkg to stop deleting everything and failing.
[17:58] <Bluefoxicy> dpkg-source: warning: ignoring deletion of file tests/test_gridfs.py
[18:02] <Bluefoxicy> clint byrum... that's who I need to find.
[19:35] <alkisg> Hi, this recent bug fix causes a regression, i.e. it no longer respects the default Xorg resolution but gnome-settings-daemon now forces the highest one: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1065979
[19:36] <alkisg> Should I file the regression as a separate bug report, or just comment in the same one?
[19:39] <Laney> alkisg: bah
[19:40] <Laney> alkisg: There's already bug #1236752
[19:41] <Laney> We should probably revert it and then Ritesh can try again if he wants to
[19:41] <alkisg> Thank you Laney, yeah, please do so :)
[19:41] <alkisg> I just commented on the first bug report a minute ago
[19:41] <Laney> FourDollars: ^ you verified this
[19:43] <mercury00> hello all. I've built a .deb package with a postinst script that edits a grub config (enables console). However, rather than call update-grub in the postinst, I'd like to 'trigger' grub to update once all packages are updated (the correct way). I believe there's a way to do this but simply cannot find it. any ideas?
[19:44] <mercury00> for instance my package might get installed when someone also installs a new kernel. rather than update grub twice, I;m sure there's a built-in way to make grub update after all packages are installed, and I'm sure the kernel packages use it but don't know how they do so. Thanks for any help.
[19:53] <Laney> alkisg: Uploaded
[19:53] <alkisg> Thank you, I'll give feedback as soon as it builds
[19:56] <Laney> bdmurray: ScottK: (picking on two of you at random) could you look at accepting gnome-settings-daemon/precise-proposed? It's a regression-update revert.
[19:58] <smoser> bdmurray, ping
[19:58] <smoser> do you have a thought on bug 1239893
[20:00] <mercury00> also, I assume this is the correct channel to ask such questions? Just want to make sure I'm not spamming the wrong place
[20:05] <bdmurray> smoser: I'm looking at your changes now.  Could you elaborate on your question though?
[20:06] <infinity> mercury00: That would require update-grub supporting triggers, which I don't believe it currently does.
[20:07] <mercury00> ah, ok - what's the general way to trigger update-menus and such though?
[20:09] <infinity> mercury00: Generally, packages handle this by triggering in their own update scripts so you don't have to think terribly hard about it.
[20:09] <mercury00> I know that when I run updates on several packages, I only see the update menus and all that at the very end of the process, but I don't know how to to that
[20:09] <infinity> mercury00: For instance, calling update-initramfs or ldconfig from a postinst will make them trigger, rather than run immediately.
[20:10] <mercury00> infinity: ah, ok so it's captured by dpkg or something then, if I call update-initramfs in postinst it triggers it instead?
[20:11] <infinity> mercury00: dpkg exports some magic variables when executing a postinst, and then if the called binary understand what that means, it can defer to a trigger instead.
[20:11] <mercury00> infinity: good to know: is there a list anywhere of what programs are /triggered/ rather than executed in postinst? I'm mostly only curious at this point, but still couldn't find any documentation on that
[20:11] <infinity> mercury00: /sbin/ldconfig is likely the simplest example of that on your system.
[20:12] <smoser> bdmurray, just wanted to know if you had a clear idea on what had regressed. i didn't understand how this path would hav regressed.
[20:12] <infinity> mercury00: There's no definitive list, as this is up to the packages themselves, not up to the distribution as a whole.
[20:12] <mercury00> infinity: aha, that makes sense
[20:13] <infinity> mercury00: The idea is that, as the caller, this should all be transparent to you.  You call what you should intruitively call (directly, or via debhepler-inserted things), and if the package does fancy things behind your back, that's its business.
[20:14] <alkisg> mercury00: $ cat debian/ltsp-client-core.triggers
[20:14] <alkisg> activate update-initramfs
[20:14] <bdmurray> smoser: did software-properties used to accept ppa: style lines?
[20:14] <smoser> yeah.
[20:15] <alkisg> mercury00: With a .triggers file you specify what trigger you want to activate
[20:15] <alkisg> You don't call update-initramfs
[20:15] <smoser> bdmurray, i just tested. and this bug existed in 0.92.26
[20:15] <mercury00> alksig: I saw some documentation on that, but couldn't find any list of what the triggers actually were,
[20:15] <alkisg> mercury00: https://wiki.debian.org/DpkgTriggers
[20:15] <mercury00> alksig: just how to call them
[20:15] <mercury00> alksig: ah, thanks,
[20:16] <alkisg> mercury00: there's a list there. also, tab in irc autocompletes the name so that you get it right :)
[20:17] <mercury00> alksig: aha, that's the one I was looking for, I was sure that ubuntu had patched grub to accept the trigger for multiple kernel updates
[20:17] <sarnold> (more like, it changes how you get it wrong :)
[20:17] <mercury00> or multiple whatever updates
[20:17] <mercury00> thanks, didn't know about autocomplete in irc
[20:19] <arges> Hi. bug 1065979 seems to be a regression for some users. How can I properly tag it so that patch gets reverted?
[20:20] <Laney> arges: I uploaded it and pinged bdmurray but he chose not to reply ;-)
[20:23] <arges> Laney: should it be tagged 'regression' or something so it gets on somebody's radar? or bdmurray can handle it since you already pinged him
[20:25] <Laney> arges: I think I did the right thing in the bug referenced from the changelog
[20:25] <Laney> anyway, off now
[20:25] <arges> Laney: ok thanks
[20:25] <mercury00> alkisg: one last question then: my package source builds several packages, so i have package1.postinst and package2.postinst --- does this mean I also want package1.triggers?
[20:26] <bdmurray> Laney, arges: I'll look at it before my EOD
[20:29] <arges> ok
[20:31] <smoser> bdmurray, i take my above comment back . i've never used that before.
[20:40] <mdeslaur> bdmurray: can I attack an apport file to an existing bug?
[20:40] <mdeslaur> s/attack/attach/
[20:40]  * mdeslaur searches for appropriate magic incantation
[20:41] <bdmurray> mdeslaur: what do you mean my apport file? a .crash file or something else?
[20:41] <mdeslaur> bdmurray: I ran ubuntu-bug on a machine without a browser, and I selected the "save for later" option. It generated an .apport file
[20:42] <bdmurray> mdeslaur: just ubuntu-bug .apport file will work
[20:42] <mdeslaur> bdmurray: but that wants to open a new bug, instead of attaching to the bug I already have...
[20:42] <mdeslaur> bdmurray: https://help.ubuntu.com/community/ReportingBugs says I should be able to use -u, but it doesn't work
[20:42] <alkisg> mercury00: not all packagesXX will need to trigger the trigger. For example, ltsp-client-core does need to trigger update-initramfs, but ltsp-client doesn't. So there's no ltsp-client.triggers file.
[20:44] <bdmurray> mdeslaur: ah so no there isn't a way to do that
[20:44] <mdeslaur> bdmurray: ok, thanks!
[20:49] <mdeslaur> xnox: I've attached requested info to the ubiquity timezone failure bug
[21:09] <mercury00> alkisg: right, only one of my packages will need to trigger something, so I'd put the instructions in my package1.triggers file then it seems?
[21:10] <alkisg> yup
[21:32] <cappyt> Hi everyone, i have a problem doing a live/installable iso based on my current system. I run 13.04 and i tried using remastersys, but it seems not working anymore... anyone has suggestions?
[21:35] <mercury00> cappyt: do you have any info about what's not working in particular? error messages? (I have no idea myself, but you'll probably get better help if you have some idea what's wrong)
[21:35] <cappyt> i can provide a log, if you want
[21:41] <bdmurray> smoser: I think you need to use strip() as DialogAdd adds a '\n'
[21:59] <cappyt> This is my remastersys.log https://docs.google.com/file/d/0B1x0krrddxExV0RJbEh1VEpDLXc/edit?usp=drive_web
[21:59] <cappyt> i can't figure out why is not creating the ISO.
[23:30] <sarnold> infinity: security team ACK on including curtin in main, details to follow in bug report "soon"
[23:45] <stgraber> sarnold: yay!
[23:46] <stgraber> infinity: was about to promote but just noticed that we only have a security team ack and not an ack from a MIR team member so I'll let you deal with that (since you've got all the hats necessary to deal with it)