| === yuning-afk is now known as yuning | ||
| 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 | 02:55 |
|---|---|---|
| ubottu | Launchpad bug 1400580 in unity8 (Ubuntu) " Color Inverse on display. Toggle Negative Image" [Wishlist,Triaged] | 02:55 |
| 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:08 |
| rbasak | mikodo: try #ubuntu-unity or #ubuntu-desktop | 03:13 |
| mikodo | rbasak, Okay. Thank you. | 03:14 |
| === athairus is now known as afkthairus | ||
| cpaelzer | good morning | 05:44 |
| pitti | Good morning | 05:48 |
| mwhudson | morning | 07:59 |
| 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:23 |
| 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 |
| ubottu | bug 1585517 in python-setuptools (Ubuntu) "Can't install for cross-building" [Undecided,New] https://launchpad.net/bugs/1585517 | 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:24 |
| 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:25 |
| 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:26 |
| 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:42 |
| ricotz | pitti, ah, thanks, will wait a bit longer then ;) | 08:43 |
| Laney | mapreri: scribus appears in appstream now, by the way | 08:47 |
| 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:00 |
| 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:01 |
| Laney | nod | 11:03 |
| Laney | thanks for tracking! | 11:03 |
| === yuning is now known as yuning-afk | ||
| === hikiko is now known as hikiko|ln | ||
| seb128 | is anyone having interest in util-linux / libblkid1? | 11:58 |
| seb128 | bug #1577768 | 11:58 |
| ubottu | bug 1577768 in util-linux (Ubuntu) "16.04 some dvd do not mount automatically (but do in 14.04)" [Undecided,Confirmed] https://launchpad.net/bugs/1577768 | 11:58 |
| 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 | 11:59 |
| 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:02 |
| 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:03 |
| rbasak | pitti: bug 1585589 - Won't Fix? | 12:06 |
| ubottu | bug 1585589 in init-system-helpers (Ubuntu) "init does leave no choice between upstart and systemd anymore" [Undecided,New] https://launchpad.net/bugs/1585589 | 12:06 |
| Laney | hey rbasak | 12:07 |
| rbasak | o/ | 12:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| Laney | And you can attach a textual description to a packageset, so you can leave future DMBs guidance | 12:11 |
| 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:12 |
| 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:13 |
| 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 |
| === JanC is now known as Guest85398 | ||
| === JanC_ is now known as JanC | ||
| Laney | launchpad treats these separately, there's archive_permission objects and packageset objects | 12:14 |
| Laney | TB can manipulate the former | 12:14 |
| 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:16 |
| 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:19 |
| 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:20 |
| rbasak | Laney: OK, so one packageset for all language support or one packageset per glob? | 12:21 |
| Laney | rbasak: Hmm, I suppose you could go two ways | 12:22 |
| 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:23 |
| 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:24 |
| === hikiko|ln is now known as hikiko | ||
| Laney | I don't see anyone else coming along for this set of things, so I'd probably do him an individual one | 12:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| === _salem is now known as salem_ | ||
| 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:52 |
| ubottu | bug 1585375 in memcached (Ubuntu) "memcached init script deprecated" [Undecided,Invalid] https://launchpad.net/bugs/1585375 | 12:52 |
| rbasak | nacc: FYI ^ | 12:53 |
| 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 | 12:58 |
| 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:01 |
| ubottu | Launchpad bug 1585589 in upstart (Ubuntu) "drop upstart-sysv" [Medium,Triaged] https://launchpad.net/bugs/1585589 | 13:01 |
| 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:02 |
| 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:03 |
| 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:05 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:14 |
| tinoco | let me check | 13:15 |
| 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:16 |
| pitti | tinoco: cheers | 13:17 |
| tinoco | aupkg01 is back on | 13:17 |
| tinoco | lets see if you can reach it | 13:17 |
| 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:18 |
| tinoco | pitti: ok, doke. aupkg02 is getting back. | 13:19 |
| tinoco | ping me if needed, cheers! | 13:19 |
| tinoco | infinity: ^ | 13:19 |
| pitti | tinoco: confirmed, thanks! | 13:20 |
| 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:21 |
| infinity | Oh, or just disconnect from the menu appears to be safe. | 13:22 |
| infinity | And less typing. | 13:22 |
| 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:31 |
| pitti | otherwise we'll have to revert i-s-h and the touch seeds | 13:32 |
| infinity | pitti: I suspect that'll fix the build issues, whether it works is a whole different story. | 13:39 |
| 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:40 |
| 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:41 |
| ubottu | Debian bug 756023 in init "init: Move "Essential: yes" from init to init-system-helpers" [Wishlist,Open] http://bugs.debian.org/756023 | 13:41 |
| infinity | pitti: \o/ | 13:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| infinity | pitti: And my narcotics seem to be finally kicking in, so I might go find a nap. See you back at work tomorrow. | 13:48 |
| === imcleod is now known as imcleod_mtg | ||
| pitti | slangasek, infinity, Laney: FYI, re-enabled s390x in britney | 14:31 |
| === johnlage_ is now known as johnlage | ||
| 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:49 |
| 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:50 |
| 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:52 |
| 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:53 |
| pitti | cking: well, we can override it | 14:54 |
| cking | that would be nice :-) | 14:54 |
| 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:55 |
| 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 | 14:56 |
| === Guest51294 is now known as adrian | ||
| === tinoco is now known as tinocoff | ||
| 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:46 |
| elopio | is that normal? should I just wait? | 18:47 |
| 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:23 |
| === afkthairus is now known as athairus | ||
| slangasek | cyphermox: ^^ do you know the answer to roadmr's keyboard preseed question? | 19:47 |
| cyphermox | roadmr: I think what you want is to preseed keyboard-configuration/layout to 'us' (or some other value) | 19:53 |
| cyphermox | roadmr: I have this full preseed that worked last I tried: http://people.canonical.com/~mtrudel/preseed/full.cfg | 19:54 |
| 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:01 |
| elopio | huh, I see it in the laptop, but not on the desktop nor the vm. | 20:03 |
| elopio | arges: I switched from the main server to a server in the UK. That works for me. | 20:05 |
| roadmr | cyphermox: thanks! let's see the diffs. | 20:07 |
| daniele_ | Hi i got error "No GSettings schemas are installed on the system" when I launch either nautilus or nm-applet | 20:14 |
| 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:15 |
| 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:16 |
| roadmr | ok, i'll try to pare it down a bit, yay | 20:17 |
| 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:18 |
| 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:21 |
| daniele_ | is anyone able to give me a hint? | 20:22 |
| 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:30 |
| 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:32 |
| daniele_ | cyphermox: thanks, btw I just reinstalled ubuntu server 10 minutes ago :( | 20:34 |
| 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:35 |
| 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:36 |
| cyphermox | daniele_: if you install ubuntu-desktop you'll get everything installed correctly | 20:37 |
| 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:38 |
| 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:39 |
| ccope | i'm logged into it, it is definitely precise | 20:40 |
| ccope | https://gist.github.com/ccope/12d952f9de1a3861e715625cce2577ee | 20:41 |
| ccope | full build log: https://gist.github.com/ccope/1811e51dfa71aee889f4fc61d5e46f46 | 20:43 |
| cyphermox | ccope: looking | 20:45 |
| 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:46 |
| cyphermox | I'm building the acl package in a precise schroot now, we'll see | 20:47 |
| cyphermox | I mean tar | 20:47 |
| ccope | yup that seems like it was it. | 20:50 |
| ccope | i think regular pbuilder uses the current release your host is running (and my host is 14.04) | 20:51 |
| ccope | had to pass --builder=pbuilder-dist | 20:52 |
| 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:01 |
| Unit193 | Has there been any efforts made on a codebrowser? | 21:41 |
| === tinocoff is now known as tinoco | ||
| === salem_ is now known as _salem | ||
| === nobuto_ is now known as nobuto | ||
| 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:40 |
| rbasak | nacc: you mean the backports pocket? I hadn't really considered that. | 22:47 |
| 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? | 22:48 |
| === g2` is now known as BrAsS_mOnKeY | ||
| === johnlage is now known as Cipher | ||
| === Cipher is now known as johnlage_bots | ||
| === johnlage_bots is now known as cipher | ||
| === cipher is now known as Cipher | ||
| === Cipher is now known as johnlage_bots | ||
| === johnlage_bots is now known as Cipher | ||
| === Cipher is now known as johnlage | ||
| nacc | rbasak: yeah, exactly | 23:28 |
| 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:29 |
| 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:36 |
| nacc | jgrimm: thanks for the import requests, found a few new bugs :) | 23:37 |
| 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:40 |
| lathiat | ah names i have not heard for a long time.. | 23:44 |
| rbasak | nacc: I see. Yes, that means my algorithm is flawed :( | 23:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| nacc | so the amendment is then that we only import a given version once for a given series | 23:49 |
| 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:50 |
| 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:51 |
| 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 | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!