[02:55] <mikodo> I am hearing of much activity happening with development of unity8. Rightly or wrongly, that is what I heard. How can I restate my desire to see this become a priority in unity8: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400580
[03:08] <mikodo> Even hearing that it looks like unity8 session has gone from being a pre-view to being the intended Xserver Ubuntu replacement. Is is time to build in replacement shading for Unity8 to replace X like my bug reads?\
[03:13] <rbasak> mikodo: try #ubuntu-unity or #ubuntu-desktop
[03:14] <mikodo> rbasak, Okay. Thank you.
[05:44] <cpaelzer> good morning
[05:48] <pitti> Good morning
[07:59] <mwhudson> morning
[08:23] <pitti> seb128: so you removed the whole upstart 1.13.2-0ubuntu24 from -proposed
[08:23] <pitti> seb128: I thought just removing the binaries from s390x would suffice?
[08:24] <Saviq> xnox, hey, could you help out with bug #1585517 - not sure what changed between vivid and xenial, but we can't cross-build unity8 any more
[08:24] <pitti> seb128: i. e. how did that proposed version blocked unity on the other arches? (I wonder what we need to "resolve" to be able to upload upstart again)
[08:24] <seb128> pitti, yes, that was what Laney suggested doing at first/seemed right, but we overlooked that the yakkety version was also missing the s390x build
[08:25] <seb128> sorry about that
[08:25] <Saviq> xnox, I tried :any and :native on the unity8 B-Ds, but that didn't help (and actually broke vivid builds, too)
[08:25] <pitti> seb128: ok, so if I'd upload upstart again, would I break anything?
[08:25] <seb128> no
[08:25] <pitti> seb128: no worries,  I'm just trying to understand what happened to avoid breakage
[08:25] <seb128> pitti, I first though that release pocket was fine and proposed created the issue, that was a mistake/overlook
[08:25] <seb128> so my bad for deleting it
[08:25] <pitti> seb128: ok, understood; so all good then
[08:26] <seb128> that was not needed/useful
[08:26] <seb128> thanks for fixing!
[08:26] <pitti> didn't hurt really
[08:26] <pitti> I just have some cleanup to upload
[08:26] <seb128> upload away :-)
[08:42] <ricotz> hello, any action on updating usb-modeswitch which conflicts with latest systemd?
[08:42] <pitti> ricotz: I already uploaded a fix
[08:42] <pitti> to systemd, to drop the Breaks:; it's not necessary for Ubuntu
[08:43] <ricotz> pitti, ah, thanks, will wait a bit longer then ;)
[08:47] <Laney> mapreri: scribus appears in appstream now, by the way
[11:00] <mapreri> Laney: nice!  Shall I assume I need to SRU it to have it work in xenial too?  (as I still see http://appstream.ubuntu.com/xenial/universe/issues/scribus.html )
[11:00] <Laney> mapreri: indeed, that'll be needed to get it fixed there
[11:00] <mapreri> ok
[11:00] <Laney> might have the same re-processing problem too
[11:01] <Laney> so if it gets an error the first time I'll have to trigger it after Contents gets updated
[11:01] <mapreri> let's worry about it after the package is fixed there too.
[11:01] <mapreri> hopefully i'll get around to it by the end of the week.
[11:03] <Laney> nod
[11:03] <Laney> thanks for tracking!
[11:58] <seb128> is anyone having interest in util-linux / libblkid1?
[11:58] <seb128> bug #1577768
[11:59] <seb128> happening in xenial, it makes the system not see e.g video dvds
[11:59] <seb128> downgrading libblkid1 to the trusty version fixes it
[12:02] <pitti> seb128: comparing "sudo LIBBLKID_DEBUG=all blkid -p /dev/sr0" with old and new lib and attaching that to the bug might help
[12:03] <rbasak> Laney (or any other former DMB member): may I have your opinion on https://lists.ubuntu.com/archives/devel-permissions/2016-May/000927.html please?
[12:03] <seb128> pitti, thanks, I'm trying to look at upstream report and git logs
[12:03] <pitti> at least to get some tangible info for upstream
[12:03] <seb128> pitti, rh has the same issue apparently so probably an upstream one
[12:03] <pitti> yeah, we don't patch libblkid
[12:06] <rbasak> pitti: bug 1585589 - Won't Fix?
[12:07] <Laney> hey rbasak
[12:07] <rbasak> o/
[12:08] <Laney> I think that the best argument in favour of using packagesets is that you can delegate their management
[12:08] <Laney> Creating the top-level objects (packagesets or PPU permissions) requires a TB member
[12:08] <Laney> But once a packageset is created then the owner can alter it
[12:08] <pitti> rbasak: I think I'll reassign to upstart to drop the upstart-sysv package; that was the plan anyway, but I wanted to leave some time between the steps to check for fallout
[12:09] <rbasak> Laney: when you say requires a TB member, do you mean by policy (I shouldn't do it) or by technicality (I can't do it) or both?
[12:09] <Laney> technically
[12:09] <Laney> you can't give someone PPU
[12:10] <pitti> rbasak: done
[12:10] <rbasak> pitti: thanks. You mean the upstart bug right? Not a PPU ACL change? :)
[12:10] <pitti> rbasak: yes
[12:11] <Laney> And you can attach a textual description to a packageset, so you can leave future DMBs guidance
[12:12] <rbasak> Can I alter a PPU set once it has been created for an uploader?
[12:12] <Laney> You can alter a packageset which has a team you are in (or you) as its owner
[12:13] <Laney> but you can't directly add upload rights to users
[12:13] <rbasak> I see. So packagesets make it much easier for a DMB to action its own decisions.
[12:14] <rbasak> And presumably I need to ask the TB to add or delete a packageset then, or to add or remove packages to users for PPU rights.
[12:14] <Laney> launchpad treats these separately, there's archive_permission objects and packageset objects
[12:14] <Laney> TB can manipulate the former
[12:16] <Laney> And process-wise for you if you agree Gunnar's globs are okay for a packageset then it becomes trivial for him to request that it's extended in the future by looking at the description of the set
[12:16] <Laney> I was in favour of making these kind of things as lightweight as possible
[12:19] <rbasak> Laney: OK so you think a packageset for Gunnar is a good idea then? Would it include all language support then, including fonts-*? Or would we treat the globbing as in their own packagesets for convenience?
[12:19] <rbasak> (I presume Launchpad can't have globs in ACLs so we'll expand them when updating)
[12:20] <Laney> rbasak: I think it'll make it easier for you to track and administer in the future
[12:20] <Laney> You need to expand the globs yourself
[12:21] <rbasak> Laney: OK, so one packageset for all language support or one packageset per glob?
[12:22] <Laney> rbasak: Hmm, I suppose you could go two ways
[12:23] <Laney> You could break new ground and make a 'personal packageset' and just add Gunnar as the only uploader of that, then make its description be exactly what you voted to approve
[12:23] <Laney> Or you could try to come up with a way of grouping these packages (in one or more sets) that makes logical sense
[12:24] <Laney> 'spelling and fonts'? Not sure
[12:24] <Laney> and im-config is a bit of an outlier in that group it seems to me
[12:24] <Laney> I don't think there's anyone else who has as many PPU rights as Gunnar after this vote, so it's kind of novel actually
[12:25] <Laney> I don't see anyone else coming along for this set of things, so I'd probably do him an individual one
[12:26] <Laney> Question is where to document that you've done it that way
[12:26] <rbasak> We can stick it in the wiki somewhere
[12:26] <rbasak> If this were a personal packageset, would it have to be a new Launchpad team just for Gunnar, or could the ACL just point to Gunnar directly?
[12:27] <Laney> I guess Gunnar will know and can remind you to do it this way next time
[12:27] <Laney> Either, but probably the latter would be easiest
[12:27] <Laney> It makes sense if you consider it an implementation detail of the PPU
[12:27] <rbasak> Got it. Thank you for your help! I think I follow this now, and in particular I follow your reasoning too, which is useful.
[12:28] <Laney> I would document this on here https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase
[12:28] <Laney> "If a person has a large PPU ACL, do this"
[12:28] <Laney> large and possibly frequently changing
[12:29] <Laney> Make sure you give it a useful description including the globs
[12:29] <rbasak> Can we change the description or does that require the TB?
[12:29] <Laney> Not sure
[12:29] <Laney> It'll come up here http://people.canonical.com/~ubuntu-archive/packagesets/ after it's created
[12:30] <Laney> So you'll go to http://people.canonical.com/~ubuntu-archive/packagesets/yakkety/gunnarhj, read the description, see that his request matches and then go ahead and execute it without needing a vote
[12:30] <Laney> (That part is the same for all packageset changes actually)
[12:30] <rbasak> OK
[12:52] <rbasak> pitti: does my answer in bug 1585375 seem reasonable to you? Is there a case for turning dh_installinit into a noop on Ubuntu if systemd units are shipped?
[12:53] <rbasak> nacc: FYI ^
[12:58] <doko> seb128, Laney: is sweetshark available? would need a LO build to build with new libs, probably merging the debian 5.1.3-1 package
[13:01] <seb128> doko, he's busy with snappy work I think, unsure if he has slots for that atm... check with him on #ubuntu-desktop?
[13:01] <infinity> pitti: Your rationale in LP: #1585589 is curious.  You can't actually break Touch any more than you already have. ;)
[13:02] <infinity> pitti: (ie: touch is already uinstallable and unbuildable due to the init change)
[13:02] <pitti> infinity: in terms of reverting stuff it's true
[13:02] <infinity> pitti: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-touch
[13:02] <pitti> infinity: so I guess it's really time to change the touch seeds to systemd-sysv?
[13:02] <pitti> Laney: ^
[13:03] <Laney> I pinged sil2100 about that earlier
[13:03] <Laney> but you might want to JFDI
[13:03] <infinity> pitti: Revert the init change or force touch to systemd, but there's no in between.
[13:05] <pitti> ok, doing the seed change then
[13:05] <pitti> emulator and n4 at least booted with systemd, and calls/text messages/wifi/3G mobile network/unity were working
[13:05] <pitti> and we do want to keep stuff buildable at lesat
[13:08] <pitti> Laney, slangasek, infinity: FYI, I temporarily disabled s390x in snakefruit:proposed-migration/code/b1/ (see bzr diff); s390x boxes have been AWOL since yesterday and xnox isn't here to resussitate them
[13:09] <pitti> Laney, slangasek, infinity: I'll be off tomorrow and Friday, so please bzr revert that delta once they come back
[13:09] <pitti> (or let me do that on Monday)
[13:09] <infinity> pitti: Does only xnox have console access to them?
[13:10] <pitti> infinity: not sure who else, but last time I sent an RT it turned out that "xnox is the man"
[13:10] <pitti> i. e. IS didn't really know where this lived and how to access it
[13:11] <infinity> pitti: Yeah, I'd expect tinoco to be able to tell you how to mangle them.
[13:11] <infinity> tinoco: ^
[13:11] <pitti> infinity: I don't have access myself, we already tried
[13:11] <pitti> i. e. xnox was telling the magic commands, but EPERM for me (even through vpn)
[13:11] <infinity> pitti: Lacking VPN access, or lacking the right passwords?
[13:12] <pitti> he did give me the passwords (back then), but firewall was blocking me out
[13:12] <pitti> s/out//
[13:12] <infinity> pitti: I'm positive I have the right network access, but have no idea what the specifics of your LPARs/VMs are.
[13:14] <tinoco> pitti: hey
[13:14] <pitti> hey tinoco, how are you?
[13:14] <tinoco> pitti: what is the machine you're talking about ? DEVACXX ?
[13:14] <pitti> tinoco: AUPKG01 and AUPKG02 (10.100.0.12 and 10.100.0.13)
[13:14] <tinoco> ok
[13:14] <tinoco> i thought they came back in yesterday
[13:14] <tinoco> at least they should have had
[13:15] <tinoco> let me check
[13:16] <pitti> tinoco: mtr stops at em1.rapid.canonical.com, but that might also be our firewall blocking icmp
[13:16] <tinoco> pitti: hum.. but the OS is up and running ?
[13:16] <pitti> tinoco: I don't know
[13:16] <tinoco> ah ok
[13:16] <tinoco> i thought it was from it you mentioned
[13:16] <pitti> tinoco: ssh says "no route to host" and I don't have any other access
[13:16] <tinoco> checking
[13:16] <tinoco> we changed network paths of this one
[13:16] <pitti> tinoco: and it's also nto processing autopkgtest requests, so I suppose it crashed
[13:16] <pitti> or someone shut htem down
[13:16] <tinoco> yep, checking
[13:17] <pitti> tinoco: cheers
[13:17] <tinoco> aupkg01 is back on
[13:17] <tinoco> lets see if you can reach it
[13:18] <pitti> tinoco: I can, thanks
[13:18] <tinoco> ok getting AUPKG02 back
[13:18] <tinoco> pitti: they are not IPLing automatically
[13:18] <tinoco> so they didn't come back after a maintenance
[13:18] <tinoco> sorry for that
[13:19] <tinoco> pitti: ok, doke. aupkg02 is getting back.
[13:19] <tinoco> ping me if needed, cheers!
[13:19] <tinoco> infinity: ^
[13:20] <pitti> tinoco: confirmed, thanks!
[13:21] <infinity> tinoco: Ahh, we've crossed streams.  Now, remind me how to disconnect from 3270 without halting? :P
[13:21] <tinoco> infinity: #CP DISC HOLD
[13:21] <tinoco> will disconnect you
[13:21] <tinoco> do not #CP LOGOUT
[13:21] <tinoco> :o)
[13:22] <infinity> Oh, or just disconnect from the menu appears to be safe.
[13:22] <infinity> And less typing.
[13:31] <pitti> Laney, infinity: ubuntu-touch-meta uploaded with dropping upstart-sysv (and a whole lot of other stuff that ./update slurped in from the recent seed changes); so hopefully images will start building agaain
[13:32] <pitti> otherwise we'll have to revert i-s-h and the touch seeds
[13:39] <infinity> pitti: I suspect that'll fix the build issues, whether it works is a whole different story.
[13:40] <pitti> yes, of course
[13:40] <infinity> pitti: Once we're sure of the change and we've passed a point of no return, the next step is to drop init out of Essential, so we can shrink chroots again.
[13:41] <infinity> pitti: Having it essential was always "wrong", but the easiest way to force the upgrade.
[13:41] <pitti> infinity: coming -- see debian bug 756023
[13:44] <infinity> pitti: \o/
[13:45] <infinity> pitti: I look forward to shrinking all my yakkety chroots and beyond.
[13:45] <infinity> pitti: upstart was transitively essential for so long that I've almost forgotten what it's like to have a proper chroot. :P
[13:46] <infinity> pitti: FWIW, that change can land at any point in this mess, we only needed it essential up to xenial to force the sidegrade.
[13:47] <pitti> infinity: right, I just didn't get around to uploading it yet, and it didn't seem particularly urgent
[13:47] <infinity> pitti: Nope, not urgent at all.
[13:48] <infinity> pitti: And my narcotics seem to be finally kicking in, so I might go find a nap.  See you back at work tomorrow.
[14:31] <pitti> slangasek, infinity, Laney: FYI, re-enabled s390x in britney
[14:49] <cking> pitti, stress-ng 0.6.04-1 has been stuck in autopkgtest testing for ppc64el for ~4+ days in  the "Test in progress" state (looking at the update_excuses page). I think it needs some kicking
[14:49] <pitti> cking: ah, I blacklisted it from testing as it keeps breaking the ppc64el testbeds
[14:49] <pitti> cking: sorry about that, it shoudl be reflected better in excuses (there's a bug about that)
[14:50] <pitti> cking: i. e. it gets stuck in an eternal testbed failure/retry loop
[14:50] <cking> pitti, ah, so is it failing the test, breaking the machine or is there something else going on?
[14:52] <pitti> cking: something like that, yes; I don't remember the precise failure mode; I'll need to run it manually and file a bug with the log
[14:52] <pitti> I thought I already did, but I think that was for a different package
[14:52] <pitti> s/I think that//
[14:52] <cking> ..I guess if stress-ng is breaking the ppc64el testbeds then is stress-ng actually failing, since it's probably a more fundamental OS issue rather than stress-ng per se
[14:53] <pitti> cking: yeah, I think it's just good enough to actually break the kernel/VM :)
[14:53] <cking> ppisati, heh, so does that mean it will never get out of -prosed because it's actually doing it's job correctly?(!)
[14:53] <cking> *proposed
[14:54] <pitti> cking: well, we can override it
[14:54] <cking> that would be nice :-)
[14:55] <pitti> cking: done now; sorry, I didn't get to fully traversing excuses.html today, too much testing backlog and too much other things to do :/
[14:55] <pitti> cking: should migrate soon
[14:56] <cking> ppisati, thanks, sorry to hassle you, I know you're v. busy
[14:56] <pitti> cking: no worries; and I'm pitti :)
[14:56] <cking> oops, autocompletion failure
[14:56] <ppisati> that's ok, i can hassle pitti for you if you want
[18:46] <elopio> arges: ping, are you around? the snapcraft source page says it was published in proposed 4 hours ago, but I can't see it in my machine.
[18:47] <elopio> is that normal? should I just wait?
[19:23] <roadmr> hey folks! I'm trying to preseed xenial but it stops at the keyboard selection thing. My (works with 14.04) preseed has these. Do they no longer work on xenial?
[19:23] <roadmr> ubiquity countrychooser/shortlist select US
[19:23] <roadmr> ubiquity languagechooser/language-name select English
[19:23] <arges> elopio: hi. let me look
[19:23] <arges> snapcraft | 2.9       | xenial-proposed/universe | source, all
[19:23] <arges> elopio: i see it in proposed
[19:47] <slangasek> cyphermox: ^^ do you know the answer to roadmr's keyboard preseed question?
[19:53] <cyphermox> roadmr: I think what you want is to preseed keyboard-configuration/layout to 'us' (or some other value)
[19:54] <cyphermox> roadmr: I have this full preseed that worked last I tried: http://people.canonical.com/~mtrudel/preseed/full.cfg
[20:01] <elopio> thanks arges, but I still don't see it. I have proposed enabled, apt update shows it. Still the latest snapcraft is 2.8.8b, coming from xenial-updates.
[20:01] <elopio> It's weird.
[20:03] <elopio> huh, I see it in the laptop, but not on the desktop nor the vm.
[20:05] <elopio> arges: I switched from the main server to a server in the UK. That works for me.
[20:07] <roadmr> cyphermox: thanks! let's see the diffs.
[20:14] <daniele_> Hi i got error "No GSettings schemas are installed on the system" when I launch either nautilus or nm-applet
[20:15] <daniele_> what is the problem I'm using ubuntu server
[20:15] <roadmr> cyphermox: thanks! I added your d-i config settings and it just worked \o/
[20:16] <roadmr> cyphermox: (only the ones for keyboard / country so not a big add)
[20:16] <cyphermox> roadmr: great :)
[20:16] <cyphermox> I don't think you need the console-setup ones, they're only there for hysterical raisins
[20:16] <cyphermox> keyboard-configuration is sufficient :)
[20:17] <roadmr> ok, i'll try to pare it down a bit, yay
[20:18] <ccope> i'm trying to backport tar from trusty to precise using `backportpackage`, but it seems like it's not rebuilding against the precise dependencies (the Pre-Depends version requirements on libc6 and libacl1 prevents installing the package on 12.04). do i need to modify the source package in some way?
[20:21] <cyphermox> ccope: simply building the package on precise should get you the right versions for libc6 and libacl1;  but for the backport you really do need to build it on precise for it to pick up the right versions
[20:22] <daniele_> is anyone able to give me a hint?
[20:30] <ccope> cyphermox, i'm running `backportpackage tar -d precise -s trusty -k MYKEY -w . -b`, which is building inside a precise chroot with pbuilder-dist
[20:32] <cyphermox> daniele_: your system is not properly installed; you're missing packages to have the gsettings properly installed. that said, this isn't a support channel. you should ask on #ubuntu
[20:34] <daniele_> cyphermox: thanks, btw I just reinstalled ubuntu server 10 minutes ago :(
[20:35] <ccope> In the source package, i see that the control file contains `Pre-Depends: ${shlibs:Depends}, ${misc:Depends}`
[20:35] <ccope> but I don't know how those get populated
[20:35] <cyphermox> daniele_: sure, but installing ubuntu-server and then desktop packages is probably the wrong way to go about things if you want a desktop
[20:36] <cyphermox> ccope: when the package gets built this gets informed by the packages used to build it
[20:36] <daniele_> cyphermox: I though ubuntu server and desktop are the same
[20:36] <daniele_> cyphermox: they both uses the same kernel
[20:36] <cyphermox> daniele_: the kernel is the same, but the packages differ a lot
[20:37] <cyphermox> daniele_: if you install ubuntu-desktop you'll get everything installed correctly
[20:38] <ccope> cyphermox, the version dependencies don't match the libraries in the precise build chroot. the version for libacl1 makes no sense, there is no version 2.2.51-8 in any of the ubuntu repositories
[20:38] <daniele_> cyphermox: that's the problem, I dont want to use unity. I wanted to install i3wm
[20:39] <ccope> daniele_, please move your conversation to #ubuntu
[20:39] <daniele_> ccope: ok, sorry :(
[20:39] <cyphermox> ccope: sounds to me like the chroot might not really be a precise one then
[20:40] <ccope> i'm logged into it, it is definitely precise
[20:41] <ccope> https://gist.github.com/ccope/12d952f9de1a3861e715625cce2577ee
[20:43] <ccope> full build log: https://gist.github.com/ccope/1811e51dfa71aee889f4fc61d5e46f46
[20:45] <cyphermox> ccope: looking
[20:46] <ccope> hm maybe it's using pbuilder instead of pbuilder-dist
[20:46] <cyphermox> I don't think that would make much of a difference
[20:47] <cyphermox> I'm building the acl package in a precise schroot now, we'll see
[20:47] <cyphermox> I mean tar
[20:50] <ccope> yup that seems like it was it.
[20:51] <ccope> i think regular pbuilder uses the current release your host is running (and my host is 14.04)
[20:52] <ccope> had to pass --builder=pbuilder-dist
[21:01] <cyphermox> ccope: well, pbuilder should always use whatever release you tell it to, but I do get it to build properly in sbuild too: http://paste.ubuntu.com/16694093/
[21:01] <cyphermox> I haven't used pbuilder in a long while though
[21:41] <Unit193> Has there been any efforts made on a codebrowser?
[22:40] <nacc> smoser: rbasak: so i think i hit a new corner-case (which rbasak, you and I may have discussed at some point) -- backports going ahead of security/updates. This happened to clamav in Dapper, where backports had 0.88.4-1ubuntu1~dapper1 while release had 0.88.2-1ubuntu1. That causes the import of 0.88.2-1ubuntu1.1 to error out as the 'tip' of ubuntu/dapper is after the to-be-imported version. Should I
[22:40] <nacc> just not import backports?
[22:47] <rbasak> nacc: you mean the backports pocket? I hadn't really considered that.
[22:48] <rbasak> nacc: if we did import it I think it'd have to be a separate branch. So shall we just not import it for now?
[23:28] <nacc> rbasak: yeah, exactly
[23:29] <nacc> rbasak: it seems to be "out of band" sort of, so i think we'd need to consider it later
[23:29] <nacc> rbasak: ok, will exclude all packages in 'backports' pocket, thanks!
[23:36] <nacc> rbasak: i think i found another case where our "only import a version (the oldest one)" once iteration through the spph is going to not be exactly right
[23:36] <nacc> rbasak: ping me when you're free, can be tmrw or later this week
[23:37] <nacc> jgrimm: thanks for the import requests, found a few new bugs :)
[23:40] <nacc> rbasak: specifically, exim4, in dapper/edgy timeframe: dapper published 4.60-3ubuntu3, which was then copied to edgy. but we only import the dapper version and don't create an ubuntu/edgy yet (since that version was already imported). Dapper then got security updates (4.60-3ubuntu3.1) and when the first 'new' Edgy import occurs (4.62-2), dpkg-parsechangelog spits an error that the range we check for
[23:40] <nacc> untagged imports (4.60-3ubuntu3.1 -> 4.62-2^ [pseudocode]) has an unknwn start version in 4.62-2's debian/chagnelog. That error is not a big deal (and I could pipe off to /dev/null to quiet it). But that means that Edgy's history includes 4.60-3ubuntu3.1 as an ancestor, which is not correct
[23:44] <lathiat> ah names i have not heard for a long time..
[23:45] <rbasak> nacc: I see. Yes, that means my algorithm is flawed :(
[23:46] <nacc> lathiat: :) i'm importing the published history for source packages into git, so it goes back to the "beginning of time" as far as launchpad is concerned
[23:47] <nacc> rbasak: i'm not sure if it's algorithm or implementation, since we added the bits for the multiple ubuntu/heads later (although I guess this also means ubuntu/devel would be wrong, so nm)
[23:47] <rbasak> I suppose copy forwards need to be imported at the "time" that they happen then?
[23:47] <nacc> rbasak: yeah, that's what i'm thinking
[23:47] <nacc> rbasak: i could another empty commit-tree that is the copy-forward when detected
[23:47] <nacc> into the appropriate branch, that is
[23:48] <rbasak> Does it need an empty commit?
[23:48] <rbasak> Since the parents would be the same in all cases I think.
[23:48] <nacc> oh true
[23:48] <rbasak> Could create a branch pointer or bump it forward for every copy forward.
[23:48] <nacc> right
[23:49] <nacc> so the amendment is then that we only import a given version once for a given series
[23:50] <rbasak> Yes, but also that on an import for a given (version, series), if the version is already imported then don't commit a second time, just locate the commit and set the branch pointer to it (with sanity checks).
[23:50] <nacc> rbasak: yep, i'm seeing where to insert that into my code now
[23:50] <nacc> it will get detected as the verison already being tagged, i think (in the pseudocode)
[23:50] <rbasak> It all makes sense, I just fear that I'm losing sight of all the use cases.
[23:50] <nacc> it's actually a lot like a sync, just ubuntu -> ubuntu
[23:50] <nacc> rbasak: yeah, there's so many corner cases :/
[23:51] <nacc> in fact, i think if i just put the duplicates back into the iterator, it will get handled just like a sync and will be correct
[23:52] <nacc> although, nm, we don't want a second commit, so not quite a sync, but the same logic -- i'll just check if what we're "sync"ing is a debian commit (ancestor of debian/sid) or not to differentiate