[01:15] <poolie> hi all
[01:16] <RAOF> Hey poolie
[05:45] <siretart> ScottK: s/CODEC_TYPE_VIDEO/AVMEDIA_TYPE_VIDEO/, and similar for audio
[08:00] <pitti> Good morning everyone
[08:05] <hrw> hello
[09:26] <Daviey> Is anyone able to fix the sponsorship queue?
[09:26] <tkamppeter> pitti, hi
[09:27] <pitti> hey tkamppeter
[09:28] <tkamppeter> pitti, it is about the color management Blueprint.
[09:28] <tkamppeter> pitti, I have done the needed packaging and MIR work as far as I could in the moment.
[09:29] <pitti> we currently have some trouble syncing colord from Debian, as we don't support tar.xz tarballs yet; but we can just reupload that as tar.bz2 or tar.gz for ubuntu
[09:30] <tkamppeter> pitti, I have updated argyll and libiccc, now with one source package (argyll), but it is still in the NEW queue due to the new binary packages. To get also the MIR (still TODO) done before FF we need to get it through the NEW queue quickly.
[09:31] <tkamppeter> pitti, does this mean that we do not get colord in in time? Or do we need to have our own independent package for one cycle until we get a new dpkg in the next cycle?
[09:32] <pitti> tkamppeter: it's a launchpad issue, not dpkg; RAOF can just reupload it in time for FF
[09:33] <tkamppeter> pitti, we also need to sync in the new package icc-profiles from Debian non-free to Multiverse and then MIR it into Restricted.
[09:34] <tkamppeter> pitti, is it a problem to do the MIRs and rebuild CUPS, Foomatic, Ghostscript, and g-c-c with colord support after FF?
[09:34] <pitti> this is a new feature, so it'll need a FFE, yes
[09:35] <seb128> well we should be able to land that before ff
[09:35] <seb128> like the package is ready, I will ping mterry and didrocks for review
[09:35] <tkamppeter> pitti, can there be done one FFE bug report for the whole color management stack?
[09:35] <pitti> tkamppeter: icc-profiles is already in oneiric/multiverse
[09:35] <seb128> then rebuilds are easy to di
[09:35] <seb128> do
[09:35] <pitti> tkamppeter: yes, with individual tasks for the affected sources
[09:35] <tkamppeter> pitti, so icc-profiles is ready for a MIR?
[09:36] <pitti> seb128: well, you probably need an additional configure switch, new build dep, and testing
[09:36] <pitti> tkamppeter: yes
[09:37] <seb128> pitti, right, well for g-c-c that seems doable
[09:37] <seb128> not speaking about the other part of the stack
[09:37] <pitti> yes
[09:38] <tkamppeter> pitti, bug 821861 did not get an answer yet.
[09:39] <pitti> tkamppeter: closed
[09:39] <tjaalton> seems like oneiric fails to mount ntfs partitions on boot
[09:39] <tkamppeter> pitti, also closed.
[09:39] <pitti> meh, LP is timeout-o-rama today
[09:40] <pitti> every other bug operation times out
[09:40] <tjaalton> "serious errors were found while checking the disk drive..", though it mounts just fine later on
[09:42] <RAOF> pitti: Launchpad *can't* handle .tar.xz when syncing, but will happily accept PPA uploads with .tar.xz?  Strange.
[09:43] <pitti> RAOF: hm, bug 619152 sas it's still pending in LP
[09:43] <pitti> RAOF: did you try it with a PPA?
[09:46] <RAOF> pitti: Yeah.  Well, Laney did.  Let me see... yeah, bug #742408 is the relevant one.  619152 is for debs with xz compression, not orig.tar.xz
[09:46] <RAOF> Have you tried syncing it across, and it failed?
[09:47] <RAOF> Time to make dinner!
[09:47] <pitti> RAOF: yes, see #u-desktop
[09:48] <tkamppeter> pitti, MIR for icc-profiles posted.
[09:48] <Laney> don't confuse .data.tar.gz with .orig.tar.gz
[09:49] <Laney> the latter works, the former does not
[09:49] <Laney> I can manually upload colord if you want?
[09:49] <tkamppeter> pitti, as bug 822587
[09:52] <pitti> Laney: perhaps the internal sync tool has an extra check for that still, so it's worth a try
[09:52] <Laney> ok
[09:53] <cjwatson> Laney: wait please?
[09:53] <Laney> ok
[09:53] <cjwatson> Laney: I want to investigate this
[09:53] <Laney> /just/ in time
[09:53] <Laney> I was hovering over enter :-)
[09:54] <cjwatson> it's good news that Debian supports .orig.tar.xz now though
[09:55] <cjwatson> pitti: what was your sync-source command line, please?
[09:55] <pitti> cjwatson: sync-source.py -b raof colord
[09:55] <tkamppeter> pitti, there is also a small, trivial printer driver package in the NEW queue, rastertosag-gdi (bug 700141), which I want to get into main and two other printer driver MIRs: c2esp for Kodak inkjets (bug 821940) and ptouch-driver for Brother label printers (bug 821943). All rather small and simple packages, consuming nearly no CD space. Would be great to have them on the Oneiric CDs.
[09:58] <cjwatson> heh, that's easy, it's a flush-syncs bug :-
[09:58] <cjwatson> )
[09:58] <cjwatson> shonky script that it is
[09:58] <cjwatson> synced
[09:58] <Laney> woop
[09:59] <pitti> \o/ thanks cjwatson
[10:00] <Laney> I think that's the first .orig.tar.xz package in Debian
[10:00] <Laney> go RAOF!
[10:34] <CoreStyx> hello, read a lot, but what is the truth: Bug, Feature, etc. ? mdadm -> RAID -> /dev/md0 ->on top lvm volume -> udevd-work : inotify_add_watch(6, /dev/md0,10)failed, No such file or directory
[10:40] <cjwatson> that sounds like you should file a bug
[10:40] <cjwatson> I don't see how it could possibly be a feature
[10:41] <cjwatson> RAID on LVM is fairly unusual (though not unheard of; I do know of somebody else using it, although not on a current Ubuntu system), so I expect it's simply poorly tested
[10:41] <CoreStyx> some people say it´s a bug, but if it would be possilbe to instruct udev to leave /dev/md0 alone instead install the watcher on /dev/mapper/lvofmd0
[10:42] <CoreStyx> but I can´t try it because I don´t know where to start on this
[10:42] <cjwatson> I don't know what the proper fix is, and wouldn't like to guess on the fly
[10:42] <cjwatson> as I say, I recommend you file a bug
[10:44] <CoreStyx> ok ... because a bug need to be proofed as a bug... and as i try to say... if somebody can tell me where to start remapping udev it would be a fix/workaround without having a developer look into it
[10:44] <CoreStyx> but ... no problem... where do I file a bug
[10:45] <cjwatson> https://help.ubuntu.com/community/ReportingBugs
[10:45] <CoreStyx> thx
[10:46] <cjwatson> in this case I have a suspicion that providing a workaround is about as difficult as providing a fix
[10:46] <debfx> cjwatson: is there a way to avoid having xterm pulled onto the kubuntu cd? I think the problem is that xorg (seeded in desktop-common) depends on xterm | x-terminal-emulator
[10:47] <debfx> and konsole (which provides x-terminal-emulator) is seeded in kubuntu-common
[10:47] <cjwatson> debfx: can't answer without investigating, but I'll have a look
[10:48] <cjwatson> debfx: is this a new problem?
[10:49] <debfx> cjwatson: no, I just noticed it because xterm gained a .desktop file
[10:50] <cjwatson> I expect fixing it would require xorg to be moved to each of the flavour-specific desktop/kubuntu-common/whatever seeds
[10:50] <cjwatson> doesn't the fallback X session make some specific use of xterm though?
[10:51]  * cjwatson is reluctant to rearrange that himself rather than letting the X people do it
[10:57] <RAOF> cjwatson: I'm not as familiar with failsafeX as bryceh is, but I don't *think* it uses xterm.
[10:59] <tjaalton> the dependency comes from debian
[11:00] <tjaalton> xorg is just a convenience metapackage
[11:01] <debfx> xinit also pulls in xterm
[11:01] <RAOF> Because _that_ has a default behaviour of starting an xterm, yes.
[11:02] <tjaalton> debfx: so you don't want to see {u,}xterm in kde menus?
[11:04] <debfx> tjaalton: I want to drop the package from the cd unless there is a good reason not to
[11:06] <cjwatson> I don't think I meant failsafeX; I think I meant one of the sessions that gdm or something used to offer
[11:06] <cjwatson> perhaps not relevant any more
[11:06] <tjaalton> gdm ships xsessions/xterm.desktop
[11:07] <tjaalton> though it doesn't depend on xterm..
[11:07] <tjaalton> debfx: that's hard :)
[11:07] <cjwatson> of course there's nothing wrong with seeding xterm in ubuntu.oneiric/desktop or something if we want
[11:08] <cjwatson> the basic problem here is that germinate doesn't (and can't be allowed to) know about what's in kubuntu-common when it's processing desktop-common
[11:09] <cjwatson> it will process dependencies in desktop-common as if kubuntu-common didn't exist; if that means that xterm is the most obvious package to select to satisfy xorg's dependency, it will do so
[11:43] <jayvee> you wouldn't think that a debian-based distro should have its dev channel suffixied with -devel
[11:43]  * jayvee shrugs
[11:44] <jayvee> I'm trying to debug a segfaulting totem but having trouble generating a stack trace (gnome 3 ppa I know, but this is a generic question)
[11:44] <jayvee> ulimit -c unlimited
[11:44] <jayvee> totem
[11:44] <jayvee> gdb totem core
[11:44] <jayvee> bt
[11:44] <jayvee> produces nothing but ?????'s
[11:44] <jayvee> however, totem-dbg is installed
[11:44] <jayvee> you'd think at least *some* of the trace would be filled
[11:45] <cjwatson> jayvee: dev channel> huh?  Debian's development channel follows the same naming pattern
[11:45] <jayvee> cjwatson: I jest, I jest
[11:45] <cjwatson> I see
[11:45] <cjwatson> perhaps https://wiki.ubuntu.com/DebuggingProgramCrash will help you
[11:54] <jayvee> okay well now I have a backtrace
[11:55] <jayvee> but now I realise I don't have nearly enough knowledge to debug the problem
[11:56] <jayvee> before I get kicked out of the channel for running unsupported software, can somebody recommend a place where I won't get my head bitten off if I ask for help debugging this gnome3 ppa issue?
[12:45] <cjwatson> jayvee: I don't know if it's the correct channel, but perhaps #ubuntu-desktop is at least a more targeted place to ask
[12:52] <jayvee> thanks
[12:52] <jayvee> interestingly enough, the problem has mysteriously vanished
[13:12] <berdario> hello
[13:13] <berdario> I tried to join ubuntu-iso and ubuntu-boot
[13:13] <berdario> but it seem that nobody's around there
[13:13] <berdario> I'm trying to look into information into an ubuntu bug
[13:14] <berdario> I'm not into #ubuntu-bugs because this has already been reported and confirmed (for the wrong package, actually...)
[13:14] <berdario> https://bugs.launchpad.net/ubuntu-release-notes/+bug/774089?comments=all
[13:15] <berdario> basically, I'm interested in this, since a friend of mine got this, and I was trying to help him
[13:15] <berdario> it seems that at least 21 people (surely more) got their macbooks half-bricked by installing ubuntu
[13:15] <berdario> (there're also some youtube videos that document this problem)
[13:16] <berdario> basically... I'm here for 2 things:
[13:18] <berdario> get in contact with whoever decided to integrate efibootmgr into ubuntu, understand why, and eventually... if possible... try to fix the bug (I don't have the hardware here, but maybe I could arrange to meet my friend quite soon)
[13:18] <berdario> and the 2nd thing, especially if it isn't possible to fix... prompt someone to look into the bug
[13:19] <berdario> because people are requesting that the release notes should be updated with it, and to warn people, it seems a quite reasonable request
[13:19] <berdario> about efibootmgr:
[13:20] <berdario> it's a software developed by dell's Matt Domsch
[13:20] <berdario> apparently it leverages upon elilo
[13:20] <berdario> this alone, seems strange to me
[13:21] <berdario> I mean: ubuntu has always used grub by default (I even tried to use grub-efi and it was working fine)
[13:21] <berdario> mixing elilo and grub seems like asking for trouble imho, but maybe I'm missing something
[13:22] <berdario> on top of that, the last update to efibootmgr
[13:22] <berdario> has been on 2008
[13:22] <berdario> the strange thing is that efibootmgr has been included in ubuntu (and only the 64bit cd) right now
[13:22] <berdario> it's present in the 11.04 disc
[13:22] <berdario> but it's absent from the 10.04.3 disc
[13:23] <berdario> so, I guess the decision to integrate it has been taken quite recently
[13:30] <ScottK> siretart: Thanks.  I now remember you had to tell me that before.  Maybe I'll manage to remember it this time.
[13:31] <berdario> ScottK: sorry if I bother you, but since you're here
[13:31] <berdario> do you know who I can refer to for decisions concerning mac support?
[13:32] <ScottK> For EFI install issues, probably in #ubuntu-installer.
[13:33] <ScottK> And IIRC, you're right.  11.04 was the first release to support EFI for boot on Macs.
[13:39] <berdario> ok, thanks... I'll look there
[13:55] <kelemengabor> hi pitti, do you have a few minutes? dpm uploaded some updated langpacks to natty-proposed, but my update-manager can't see them. could you check what happened to them?
[14:13] <jml> Hello, I've just submitted a very simple patch – https://code.launchpad.net/~jml/ubuntu/oneiric/python-defaults/swallow-stderr-812960/+merge/70744. Not really sure what happens now.
[14:14] <nigelb> it shows up on the sponsorship page and someone picks it to be sponsored.
[14:15] <geser> btw: is the sponsoring page broken or does my link point to the wrong location?
[14:15] <Laney> looks broken to me
[14:15] <nigelb> geser: strange. I was just about to ask the same question
[14:15] <Laney> uh oh, and bdrung and dholbach are both away
[14:16] <nigelb> I'm using pre-beta browser, so I thought it was just me.
[14:16] <geser> Laney: you know, as usual such bugs only happen when everybody who knows how to fix them is on vacation
[14:18] <infinity> jml: You might also want to poke doko and/or ScottK about getting your patch into Debian.
[14:19] <infinity> jml: (The patch itself looks good and obviously correct to me, if I wasn't running to breakfast, I'd sponsor it to Ubuntu for you, but it may as well go to Debian anyway)
[14:19] <jml> infinity: thanks. I'll do that.
[14:23] <ipc> howdy… can someone point me to more information re: https://wiki.ubuntu.com/Core ?
[14:24] <ScottK> jml: I've asked the dh_python2 developer (POX) to look at it.  Assuming he agrees (I'd be surprised if he didn't), I'll commit it to the Debian VCS for the package.
[14:24] <ipc> the procedure mentions unpacking 'Ubuntu Core' but not where to download the archive
[14:25] <nigelb> geser: heh
[14:25] <nigelb> geser: "knowing" how to fix isn't a problem. Access to fix it is differnt ;)
[14:25] <nigelb> I could probably spend a fe minutes and understand it.
[14:26] <Laney> i'm sure you can find someone to deploy it for you
[14:26] <Laney> dunno where the code is though
[14:26] <nigelb> yeah, I'm looking around for that.
[14:27] <infinity> ipc: http://cdimage.ubuntu.com/ubuntu-core/
[14:27] <ipc> beautiful
[14:27] <ipc> thanks!
[14:28]  * infinity was not aware persia had written that wiki page...
[14:28] <infinity> ipc: His page doesn't, for instance, mention that we only ship -core tarballs for armel right now.  So, hopefully that's what you want. ;)
[14:29] <geser> nigelb: https://code.launchpad.net/~ubuntu-dev/ubuntu-sponsoring/trunk
[14:29] <nigelb> Just got there.
[14:30] <nigelb> So, ~ubuntu-dev can commit to it, so someone can merge changes in.
[14:30] <nigelb> Now to find the fix.
[14:30] <ogra_> infinity, 35M ? we should really lose some fat here :P
[14:31] <ipc> infinity: I'm just eager to get a peek :)  I really like the whole idea
[14:31] <ogra_> seems the release subdir is lacking the manifest
[14:31] <infinity> ogra_: I know, I know.
[14:31] <infinity> I have a TODO about fixing the release scripts to love -core correctly.
[14:31] <infinity> But it's also a day off today, so.  Later. ;)
[14:31] <ipc> thanks, take care!
[14:32] <ogra_> yeah, cure your jetlag !
[14:33] <infinity> Syrup and waffles cure everything.
[14:34] <ogra_> not without coffee though
[14:35] <ScottK> jml: Committed to bzr in Debian.  Thanks.
[14:37] <ScottK> jml: http://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults-debian/revision/261?start_revid=261
[14:38] <nigelb> Loggerhead? Interesting.
[14:40] <nigelb> Didn't know it was a separate project till now :)
[14:43] <cjwatson> always has been
[14:46] <jml> ScottK: thanks
[14:47] <jml> ScottK: is there stuff I should (could?) have done to make that easier for you? Work that you did that I could have done myself?
[14:48] <cjwatson> hallyn: does http://paste.ubuntu.com/661171/ look right to you?  I have a sync from Debian I'd like to do (for WPA support in d-i) that requires libnl3, and it seems like least paperwork if we just convert everything in main to libnl3 in one go ...
[14:48] <cjwatson> hallyn: I can't really test that, but it does at least build
[14:49] <ScottK> jml: If the branch had been against the current python-defaults head in Debian, that would have made it easier, but it's a bit unreasonable for me to expect you to know that.  Including a proposed debian/changelog entry would have been good.
[14:49] <ScottK> Personally I like using diff and patch better than VCS merges, but eventually I'll get over it, I'm sure.
[14:49] <jml> ScottK: you would have had to change the 'who' bit of the changelog if I had provided such an entry, right?
[14:50] <ScottK> jml: If you had, I probably would have left your name on it rather than mentioning you in the text of the entry.
[14:50] <ScottK> dch makes it trivially easy to change it in any case.
[14:51] <jml> ScottK: ok, thanks.
[15:10] <hallyn> cjwatson: (at a sprint this week, sorry for slow responses) : i don't know what that lib is offhand.
[15:16] <cjwatson> hallyn: the netlink socket handling library
[15:17] <cjwatson> you were just last uploader, maybe I should be asking somebody else
[15:21] <hallyn> cjwatson: is there an open bug for this?
[15:25] <cjwatson> no
[15:25] <cjwatson> just from discussion here and on #ubuntu-desktop today
[15:33] <jtaylor> barry: hi, you did you get my argparse message?
[15:34] <barry> jtaylor: i did, but i'm just back from a week off so still catching up
[15:46] <Laney> would appreciate a moderation on u-d-a, providing the mail is alright
[15:50] <cjwatson> Laney: done
[15:51] <Laney> ty
[16:02] <pitti> kelemengabor: hm, they are not in the unapproved queue
[16:03] <kelemengabor> pitti: dpm swears he uploaded... to somewhere
[16:03] <kelemengabor> but as he is now on holiday, we cannot ask :(
[16:03] <pitti> kelemengabor: https://launchpad.net/ubuntu/+source/language-pack-es/+changelog
[16:03] <pitti> kelemengabor: seems someone actually accepted them
[16:04] <cjwatson> I did
[16:04] <cjwatson> was that OK?
[16:04] <pitti> they should be fine, yes
[16:04] <cjwatson> skaet was asking about them
[16:04] <pitti> thank you
[16:04] <kelemengabor> cjwatson: thanks!
[16:04] <pitti> kelemengabor: so you can send out the call for testing
[16:04] <cjwatson> that was only about an hour ago though, so they may not quite be on mirrors yet
[16:04] <kelemengabor> sure, in a moment
[16:08] <kelemengabor> hm, not yet on the main server, I'll wait a bit
[16:08] <pitti> kelemengabor: they'll also need a couple of hours to build
[16:09] <pitti> kelemengabor: see https://launchpad.net/builders
[16:09] <kelemengabor> oh... I thought these are already the binaries :(
[17:08] <jtaylor> is a MIR planed for underscore? it would be needed for a new python-sphinx version which has the very useful dh_sphinxdoc debhelper
[17:44] <jtaylor> uglifyjs is also needed for it
[18:38] <tkamppeter> pitti, ping
[18:57] <mdeslaur> Is it a known issue that nothing is setting XAUTHORITY on oneiric alpha3?
[19:06] <micahg> can someone give synaptic back please
[19:11] <mdeslaur> Is there no way to add rights to a user using "User Accounts" in oneiric anymore?
[19:15] <cyphermox> micahg: doing it now
[19:17] <micahg> cyphermox: thanks
[19:38] <roadmr> hey folks! gconf{video,audio}sink are no longer in gstreamer0.10-plugins-good, and the replacement gsettings{audio,video}sink are in gstreamer0.10-plugins-bad, are there plans to move this to -good?
[20:27] <ScottK> doko: Could you re-run your dh_python2 conversion script against the Kubuntu desktop manifest so I can find out if there are any additional packages we need to convert for Kubuntu (I think they are all done).
[20:29] <doko> ScottK: it's just running grep-dctrl for the status file from the image
[20:29] <doko> barry: ^^^
[20:30] <ScottK> So you're going to make me have to think about it ...
[20:30] <ScottK> OK.
[20:30] <barry> ;)
[20:30] <doko> trying to catch up on things, so this is not my priority
[20:31] <doko> no, I didn't save the command
[20:31] <micahg> ScottK: you could also look at the germinate output for the kubuntu seeds
[21:02] <dupondje> aptitude broke down ? :)
[21:03] <micahg> no, there's an apt transition in progress
[21:04] <dupondje> hehe ok, lets hope apt-get keeps working to upgrade ^^
[21:16] <slangasek> cyphermox: is there a transition plan for libnl3?  there are a number of other packages besides NM using libnl1 in main
[21:19] <bryceh> @pilot in
[21:22] <bryceh> http://reports.qa.ubuntu.com/reports/sponsoring/ seems to be busted
[21:22] <dupondje> yea
[21:22] <dupondje> since some days
[21:24] <bryceh> jeez the UbuntuDevelopment/CodeReviews wiki page is wordy...
[21:27] <tormod> bryceh, can you please sync #808679 ?
[21:34] <bryceh> tormod, hmm not sure I have rights for doing syncs
[21:35] <tormod> bryceh, as a dev you can ack it and sub u-a
[21:36] <bryceh> tormod, well I can do that, although I think you need someone with archive rights to actually sync it
[21:40] <bryceh> tormod, sound good?
[21:40] <tormod> bryceh, yes thanks, it will surely help
[21:42] <bryceh> hmm, this makes me curious why sync requests go through ubuntu-sponsors?  wouldn't it make more sense for them to go directly to ubuntu-archive?
[21:42] <Laney> because they are the same as any other upload
[21:42] <micahg> bryceh: the syncs aren't always appropriate/buildable
[21:42] <Laney> and need to be checked for sanity
[21:43] <tormod> bryceh, I guess it is to spare the u-a people from all kinds of requests from non-devs
[21:43] <bryceh> couldn't someone with ill intentions just sub ubuntu-archive directly?
[21:44] <Laney> i suppose archive admins check that syncs have been properly acked
[21:44] <micahg> it's to spare the AAs from having to verify the syncs
[21:44] <bryceh> hmm interesting *shrug*
[21:44] <bryceh> seems like a loosey goosey process to me but whatever :-)
[21:45] <micahg> when people subscribe AAs directly, it usually gets kicked back to the sponsor queue unless the AA is feeling benevolent
[21:46] <micahg> s/AAs/u-a/
[22:08] <natschil> Good day. Is there an easy way of making a script/ubuntu package for ubuntu that will make changes to a script that is in /lib persistent even if the script is updated by the package system?
[22:17] <RAOF> natschil: It sounds like you're after dpkg-divert
[22:20] <bryceh> micahg_, how about sync requests that are pulling new packages into ubuntu?  Do those just get passed on to -archive or do they need further processing/review?
[22:20] <natschil> RAOF: cool. but doesn't that simply lock a file completely for any updates? though maybe that is what I want.
[22:20] <bryceh> micahg_, e.g. #821550
[22:20] <micahg_> bryceh: same deal, make sure the package is something we want in this cycle and make sure it's buildable
[22:21] <micahg_> bryceh: and that's already in oneiric :)
[22:23] <ajmitch> I think the point of that sync is just so that it autosyncs next time
[22:23] <bryceh> ajmitch, won't it require a fakesync?
[22:23] <micahg_> yep, but most of those aren't worth doing at this point
[22:24] <ajmitch> bryceh: only if the orig.tar.gz is different
[22:24] <micahg_> i.e. explicitly filing bugs for those syncs, not processing existing ones filed
[22:27] <micahg_> unless there's something else interesting in the Debian upload
[22:28] <bryceh> micahg_, ok so you think these types of sync requests (with no functional changes other than the version number) should be wontfixed?
[22:29] <micahg_> bryceh: no, you can process them, but inform the requestor that efforts are best spent elsewhere (the time to do them are before DIF since they have no affect afterwards)
[22:29] <Laney> you might as well ack them if someone has taken the time to check, but advise the submitter that it could have waited until next cycle (and if they want they can put a note on mom to indicate they have checked)
[22:30] <ajmitch> hopefully by then they'll be syncable via the LP UI/API
[22:33] <micahg_> it took a while for me to understand the reasoning, but now I agree with it
[22:34] <bryceh> alrighty, thanks
[22:40] <natschil> RAOF: thanks for the help, I think I'll use dpkg-divert
[22:47] <ion> Cool, aptitude segfaults now. :-)
[22:49] <RAOF> Oh, it's missing appropriate dependencies for the apt transition?
[22:50] <ion> It seems libapt-something was updated but apt was held back. aptitude segfaulted after that upgrade. When i upgraded apt with ‘apt-get install apt’, that removed aptitude.
[22:51] <slangasek> so a no-longer-installed package segfaults?
[22:52] <ion> aptitude safe-upgrade: apt was held back, libapt-something was updated, aptitude stayed installed. After that: aptitude segfaulted. apt-get install apt: apt was updated and aptitude was removed.
[22:52] <slangasek> ah
[22:58] <cjwatson> slangasek: all the libnl reverse-build-deps are in progress
[22:59] <cjwatson> slangasek: I asked for that change because WPA support in netcfg depends on a new wpasupplicant version which switched to libnl3, and that's a pretty high-value thing
[22:59] <cjwatson> I think we can manage it
[23:11] <slangasek> cjwatson: ok, no worries - just hadn't heard anything prior to seeing it show up in the components-mismatches list, and it was worrying to see that it was a separate source package
[23:14] <cjwatson> slangasek: libnl3 ought to supersede libnl in main; I'm not sure why it's separate in Debian, but there were only eight reverse build-deps so I'm working to make sure we can just swap it
[23:15] <cjwatson> (presumably because there are some API changes as well as just ABI)
[23:19]  * slangasek nods