[00:28] nacc, ugh. [00:28] 11/01/2016 15:18:41 - DEBUG:Setting importer/ubuntu/devel branch to 'importer/ubuntu/breezy' (6de0c9f7d926b4c1f434bf5508eaeb675c29fea8) [00:28] looks like something amuck [00:29] http://paste.ubuntu.com/23413992/ [00:34] smoser: um, shouldn't you have reversed the list? [00:34] smoser: quick debug shows zesty is the last entry [00:35] smoser: feel free to fix and push yourself [00:35] apparently yes [00:35] i swear i looked at that [00:35] smoser: need to walk the dogs :) [00:35] :-( [00:35] well, you're explicitly sorting on version by number [00:35] so that will come through in ascending order, aiui [00:35] yeah. [00:35] and then needs to be reversed for the names [00:35] i would do that in the caller, though [00:35] can i push that ? [00:36] in case the API is useful on its own later [00:36] you should have write access to the importer tree, yeah [00:36] ok. [00:36] smoser: yeah, you're in the ownership group [00:42] nacc, pushed the most simple fix for now [00:55] smoser: thanks! [00:56] your idea was not bad, but required more code change than i wanted right now === g2[cubs-ATL] is now known as g2 [04:20] daylight savings sucks, a.k.a. too early good morning :-) [04:20] +1 to the former. [06:44] hi, does forgetting (my bad) to include the orig tgz on a merge dput qualify to use dput --force after rebuilding with -sa (no need for an ..ubuntu2 for that right)? [06:45] last cycle my merges were all uploaded by others, since I got permissions I only had fixes so I missed to add the orig tarball to the upload [06:46] easy to fix, but I'd at least hear one person say "yes dput force is ok in that case" [06:52] cpaelzer: dput --force is, AFAIK always fine - launchpad will just reject your upload if its not. [06:54] RAOF: I thought that it'd be ok, but on any --force I'm shy using it the first time :-) [06:54] RAOF: thanks [06:54] Yup, better to be sure! [06:55] For us, --force only disables local checks. We don't have the access DDs have to the submitting filesystem, so we can't use things like dcut (and we don't have to be as careful ☺) [06:58] I'm good with less power to screw things up atm :-) [07:26] hi pitti can you please run xapian-core libsearch-xapian-perl testsuite against -proposed pocket? [08:08] pitti: hey! I'm trying to get the new dbus package pushed through -proposed since over a week, but I see that there's still a lot of tests that are 'Test in progress' since that time and not really getting executed [08:42] mardy, they, that signon-ui bug you just commented on, did you see that Lan_ey already added debug logs in previous comments? [08:44] seb128: ouch, indeed [08:44] seb128: and actually the problem this guy is reporting is slightly different... [09:19] mardy: I'm having that bug again atm as it happens [09:19] I've just been minimising the window though [09:19] if you close it it just comes back [09:20] Laney: seems like I forgot some check when migrating signon-ui from webkit to oxide, I'll fix that [09:20] phew, thanks [10:10] rbasak: for our discussion on passing through proposed and the binary dependency becoming uninstallable [10:11] rbasak: is the ordering of uploads strict so that I can upload the dependent one right away? [10:11] rbasak: or do I have to wait until it shows up in update-execuses [10:11] I want to avoid it gets rebuild too early [10:11] and by that misses to pick up the new abi [10:14] cpaelzer: you either need to wait until the binaries are published in the proposed pocket, or the build depends needs to be versioned. [10:14] We don't usually used versioned depends for this kind of thing, so I guess then ordering matters. [10:15] rbasak: yeah it is only versioned in the sense that it depend on a virtual ABI package, but that only gets there once the former is build [10:15] s/build/built/ [10:16] rbasak: thanks - so I'm gonna wait with the follow up dput until it shows up [10:16] ack [11:09] zul: monasca-statsd has a copyright owner not mentioned: Copyright (c) 2012, Datadog [11:09] zul: you also only packaged the python2 libs, not the python3 ones ... === marcusto_ is now known as marcustomlinson [11:32] sil2100: sprint, no IRC time -- is it queued? http://autopkgtest.ubuntu.com/running is full [11:33] pitti: didn't check, but even if - is it possible those are *still* queued after 11 days of waiting? [11:34] sil2100: oh, no; then they were probably victim of some cleanup/bug [11:35] sil2100: requeueing them now, but it'll take some time to catch up with the queue [11:36] Thanks! :) [11:36] sil2100: not the "always failed" ones as they aren't blocking/relevant [11:36] * pitti off again === hikiko is now known as hikiko|ln [12:13] pitti: Hi Martin! When there are .mo files for a textdomain in both /usr/share/locale and /usr/share/locale-langpack, gettext seems to use the former. Shouldn't the one in /usr/share/locale-langpack have precedence? The reason for to my question is apt, more precisely comment #7 in bug #1637801. [12:13] bug 1637801 in gettext (Ubuntu) "Incorrect Russian translation of "apt list --upgradeable" results" [Undecided,New] https://launchpad.net/bugs/1637801 [12:30] doko: thats because there isnt any python3 support for it yet [12:38] cyphermox: would you mind handling bug 1629644 please? It's a (rather late) claimed regression in your SRU of 0.4.9-3ubuntu7.5. [12:38] bug 1629644 in multipath-tools (Ubuntu) "Trusty: failure to detect device with 0.4.9-3ubuntu7.5" [High,New] https://launchpad.net/bugs/1629644 === hikiko|ln is now known as hikiko [12:56] powersj: FYI, bug 1635929 is a dupe - I've marked it. Downgrading from MariaDB 10.0 to MySQL anything is broken. [12:56] bug 1490071 in mysql-5.7 (Ubuntu) "duplicate for #1635929 MySQL 5.6 refuses to install on systems that have had MariaDB 10.0 installed, preventing users from reverting to MySQL without manual intervention (aka mysql flag file system needs a redesign)" [High,Triaged] https://launchpad.net/bugs/1490071 [12:56] (not supported upstream) [13:00] Mirv: I promoted llvm-toolchain-3.9. please do the next mesa update using this version [13:01] cyphermox: also I'd appreciate some help triaging bug 1636145 please. [13:01] bug 1636145 in multipath-tools (Ubuntu) "multipath: Unrecognised multipath feature request" [Undecided,New] https://launchpad.net/bugs/1636145 [13:28] jbicha: are you going to look at the pcre3/pcre2 transition then? [13:41] doko: I think that's beyond my abilities as I don't think Debian or the upstreams are trying to make that transition now [13:42] urgh [13:42] and the list of affected packages is extensive [13:42] doko: tjaalton will be happy to do so [13:43] ahh, again the wrong T. [13:58] rbasak: thank you [14:06] doko: sure thing, once mesa 13 is ready [14:06] turns out 12 wasn't too happy with 3.9 [14:06] at least some games aren't [14:16] rbasak: done, thanks. [14:17] Laney: hi! When you have some time, can you please try https://bileto.ubuntu.com/#/ticket/2135 and see if it fixes the issue? [14:17] * cyphermox goes back to the salt mines (network at Plumbers has been terrible, not sure if it will be any better today) === daniel is now known as Guest19937 === Guest19937 is now known as Odd_Bloke [14:41] cyphermox: thank you! [14:43] Is there any reason why there is no warning of the fact that "atp-get upgrade" is running when the user decides to turn off the computer (using the GUI) ? [14:45] slangasek: any opinion on https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1613914/comments/4 please? Amos is upstream and active in Debian packaging of squid now too. His opinion contradicts your upload in 3.5.12-1ubuntu4 I think. [14:45] Launchpad bug 1613914 in squid3 (Ubuntu) "squid upgrade fails when user has custom cache_dir" [High,Confirmed] [14:48] caribou: not technically I gues seeing this http://askubuntu.com/questions/771227/how-can-i-get-a-warning-before-restart-shutdown - while clearly it needs tests/polishing it seems to be able to do what you want [14:48] cpaelzer: ok, I'll check this one out [14:49] cpaelzer: this situation hosed my wife's laptop : it would not reboot and got a kernel panic on each reobot [14:49] s/reobot/reboot/ [14:51] caribou: there are different suggestions on http://askubuntu.com/questions/702156/prevent-ubuntu-from-shutdown-before-background-automatic-updates-complete [14:51] caribou: an adaption of the case I linked before for apt/update-manager and such [14:52] caribou: I sometimes wonder if it is destiny that such things always hit family members of developers of if there are more out there [14:55] mardy: OK, it'll have to be tomorrow though because I'm not at that computer right now [14:58] cpaelzer: I got the _notorious_ cellphone picture of a kernel backtrace as a bug report :) [14:58] I wonder if that's a consequence of unattended-upgrades being enabled by default. [14:58] rbasak: not in my case, landscape was running the upgrade [14:58] Prior to that, update-manager (or whatever the GUI stuff is) fired up, and at that stage it was obvious. [14:58] Ah [14:59] rbasak: so maybe landscape triggers a different behavior [14:59] (I had forced a landscape upgrade to *fix* the DirtyCOW issue) [14:59] caribou: I feel there should be a bug somewhere for this. This kind of race is pretty bad for users. [14:59] rbasak: indeed [15:00] rbasak: the kernel backtrace was pointing to a missing superblock so it looked more like a dead HDD than just a failed kernel upgrade [15:08] Laney, seb128: what's the future of ubuntu-kylin-software-center? [15:08] Ask the Kylin team [15:08] what Laney said [15:09] hmm, who is this? [15:15] smoser: apport went from 13404 to 14636 KB by adding pristine-tar and upstream branches [15:15] rbasak: --^ [15:18] how many tarballs is that [15:18] smoser: 122 [15:18] and do you have a branch that i can try ? [15:18] smoser: i think i sent it to you yesterday? [15:18] one sec [15:19] nacc: I think what I dislike about that approach is that it adds state (the pristine-tar branches themselves). If we decided we wanted to change how it's done, we'd be in a pickle because a simple update to the tool might not be enough - we'd have to modify the state too. OTOH, grabbing it from Launchpad on the fly involves no additional state. === didrocks1 is now known as didrocks [15:19] smoser: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+ref/orig_tarball [15:19] rbasak: absolutely, i understand, smoser just asked for the data [15:19] rbasak: the biggest advantage, as i see it, is that it follows debian [15:20] i dont follow your comment [15:20] "we'd have to modify the state too". [15:20] rbasak: and it's really not trivial to go from a an arbitrary srcpkg and (upstream) version to a tarball [15:20] rbasak: doable, but not trivial :) [15:20] if we decided the pristine tarballs are not useful, then we can delete them from the git repositories and git gc and change tools to not use them. [15:20] Debian isn't married to pristine-tar though. It's just one of the dozen ways they do it. [15:21] (note, i'm pretty sure we can arbitrarily *add* the pristine tarballs at any point also, and not affect any thing) [15:21] other than size [15:22] smoser: sort of -- it would need a different implemetnation to go back to the beginning of time for one branch [15:22] smoser: but theoretically possible, yes :) [15:22] doko: #ubuntukylin-devel AFAIK [15:22] rbasak: yeah, I understand -- again, not suggesting it to merge even [15:22] rbasak: just that it's there, and does seem to work [15:24] rbasak, can you explain further what you dont like ? we'd not be "married" to it in any way either. [15:25] smoser: it feels brittle to me to rely on it in the tooling. I don't particularly object to having pristine-tar branches in the imported tree however. [15:25] smoser: brittle in the sense that it is imported in a particular way (the choice of pristine-tar, the format/version pristine-tar is using, the format/version of the tarballs and compression, etc) and then tooling must stick to that. OTOH, doing it afterwards from Launchpad involves none of that, and can be changed much more easily later. [15:26] rbasak: i'd never rely on it; if it's there, i'd use it and probably double-check the hashes match against a known good dsc [15:26] rbasak: and i'd fall back to a cache [15:26] I accept that in practice it is said that this hasn't yet been an issue with pristine-tar in particular. However, there's still a possibility, and there is none with a state-free system. [15:26] or v.v. [15:26] theres not any real need to double check hashes [15:27] launchpad wont let you upload the bad one [15:27] smoser: there is if you can usd-build from any directory [15:27] smoser: remember, pathological :) [15:27] i dont follow [15:27] there is a difference from the hash being different [15:27] and the tarball contents being different [15:27] I guess I mainly don't understand any real world practical benefit to doing it with pristine-tar over a direct method. If there is, then that's fine, and I still have no objection to the branch being there. [15:28] no reliance on network is the benefit [15:28] smoser: the uploads will get rejected, yes [15:28] also i guess with prisitne tar baranch we probably get upstream/ tags also [15:29] smoser: so in effect it's the same; but i'd like to detect badness of that type earlier [15:29] which is a benefit [15:29] smoser: yes, we do [15:29] as without that, you coudlnt even create the orig tarball if you wanted. [15:29] well, not trivially anyway. [15:29] smoser: without the upstream tags? [15:29] where as with the tag, if you didnt' care about the tar hash matching, you can 'git archive' [15:30] smoser: no reliance on the network? You need to clone the git repo. Have usd-clone grab the orig as well if you like. [15:30] those two events are likely hours apart [15:30] so there needs to be network at some point [15:30] certainly at clone [15:31] i think smoser is saying there doesn't need to be at build as well [15:31] i still think this is not a typical use-case :) [15:31] Right, but if the orig is grabbed at clone time, then it's available. [15:31] *what* orig, though [15:31] sure... and just for fun, you'll grab all orig tarballs :) [15:31] we don't know what is about to be built at clone time [15:31] And if he wants all available orig tarballs from pristine-tar because then it's cloned, then fair enough, but no need for our tooling to do it that way by default - it's a separate use case. [15:31] i did ask for a bug :) [15:35] rbasak: there isn't a case where an orig tarball gets *added* to a package and the upstream version is the same? if we were to do that in an ubuntu package, i think the cache doesn't work -- also how does that work in practice (what tells dpkg-buildpackage there is a second orig tarball to use)? [15:36] That's a good question. If it were up to me, I wouldn't permit that. But I don't know what Debian/Launchpad do. [15:36] * rbasak wonders if cjwatson might know ^ [15:36] rbasak: ack, just working on usd-build and gets all these kinds of questions :) [15:37] cjwatson: or, generally, if you have some advice on the 'best way' to work from an arbitrary source pacakge directory to the orig tarballs needed to build that package [15:38] rbasak: ah, it seems it looks for .orig-component.tar.ext [15:39] where component is a well defined regex [15:39] and is used to name the subdir [15:40] rbasak: but given only an unpacked source pacakge, i see no way of determing that :/ [15:40] and i've forgotten how to type, clearly too :) [15:42] rbasak: let's assume it's not allowed for now [15:42] OK [15:42] as it's giving me a headache too early in the morning :) [15:51] Hello everyone and appdevs, I am currently working on the Telegram app but I am having some trouble getting an executable when building the latest (https://code.launchpad.net/~libqtelegram-team/telegram-app/telegram). It builds fine on 16.04 but on 16.10 I keep getting "../telegram-app/build_desktop/lib’: No such file or directory". Has anyone else come across anything similar on any of your apps? Any help would be appreciated. [15:54] nacc, http://paste.ubuntu.com/23416635/ [15:54] that is the whole list of 'server-cares' (minus ruby, which i just removed, and 'linux', which i feel like just special casing out) [15:57] smoser: awesome! can you file bugs for the ones that are not DownloadErrors (and maybe one bug for the DownloadErrors)? [16:10] juliank: Could you have a look at bug 1592817? [16:10] bug 1592817 in python-apt (Ubuntu) "gdebi-gtk crashed with ValueError in update_interface(): could not convert string to float: '0,0000'" [High,Triaged] https://launchpad.net/bugs/1592817 [16:10] aargh, not one of those [16:11] I assume it's one of our all time favourite string formatting bugs in apt [16:12] bdmurray: That should be fixed in a reasonably current apt, but that user still runs an apt from early june [16:13] juliank: could you be more specific about reasonably current? [16:13] smoser: thanks! i'm guessing that LP: #1638614 is me assuming i can extract authorship correctly and not handling when that fails [16:13] Launchpad bug 1638614 in usd-importer "linux-base, module-init-tools fail import: AttributeError: 'NoneType' object has no attribute 'group'" [Undecided,New] https://launchpad.net/bugs/1638614 [16:13] smoser: LP: #1638612 is going to need a parent overrides, i think [16:13] Launchpad bug 1638612 in usd-importer "golang-golang-x-net-dev fails import: AssertionError source pkg version != changelog version" [Undecided,New] https://launchpad.net/bugs/1638612 [16:14] smoser: as it's published incredibly poorly :) [16:14] smoser: that particular publish implies an epoch change, which wasn't done [16:14] juliank: I seem some with 1.2.14 which is in xenial-proposed. [16:14] No, there were fixes all the time. But the one that was actually released in 16.10 should probably be fine. I'll look at the code now, but there were a lot of fixes in later 1.3 releases. [16:14] nacc, i'm just the messenger :) [16:14] bdmurray: It should not happen at all in 1.2 [16:15] smoser: ack, mostly just notes to myself [16:15] Unless you set the locale with C++ functions [16:15] yeah [16:15] i filed all those failures [16:16] juliank: here's an example - https://errors.ubuntu.com/oops/752e2da8-a0f3-11e6-8735-fa163e839e11 [16:18] bdmurray: The bug in question should be a duplicate of bug 1611010 - that fixed the problem [16:18] bug 1611010 in ubiquity (Ubuntu Xenial) "yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: ''" [Critical,Triaged] https://launchpad.net/bugs/1611010 [16:18] Or well, the commit fixing that bug also fixed the other one [16:20] juliank: so its fixed in yakkety, but not xenial then. [16:21] bdmurray: I can't see the xenial instance, but I specifically did not merge any of that stuff because it only happens if your app calls std::locale::global [16:21] Which we switched apt to at some point in the 1.3 series from setlocale() [16:23] (WRT can't see: I just filed a request for access to the error tracker, but that needs manual approval) [16:24] juliank: there you've been approved [16:24] Thanks [16:24] This is kind of weird that this happens [16:25] It also happens w/ the release upgrader - bug 1633219 [16:25] bug 1633219 in ubuntu-release-upgrader (Ubuntu) "Upgrade to yakkety fails due to non-us locale" [Undecided,Confirmed] https://launchpad.net/bugs/1633219 [16:26] bdmurray: Ah I might have been confused a bit when doing the later 1.2 releases, I actually cherry-picked the first "prevent C++ locale formatting" commit. [16:26] So, I'll take a look if I can cherry-pick that into 1.2.y for xenial [16:26] That said, we still need to get 1.2.15 in first :/ [16:27] juliank: that'd be great. Do you mean 1.2.14 which is in -proposed or something newer? [16:27] bdmurray: 1.2.14 has been superseded by 1.2.15 in the queue [16:27] Oh, I can help with that too [16:29] could we get a rebuild of devscripts so that zesty is default instead of yakkety? [16:31] bdmurray: That would be great. Once we have 1.2.15 in (which accumulates 4 months or so of bug fixes :/) we will start seeing smaller (hopefully) monthly updates. [16:32] 1.2.15 was far too large, but I never managed to upload the individual bug fix releases corresponding to the 1.3 preview releases (it really should have been 4 releases or something) [16:44] bdmurray: I think I got all the patches in https://github.com/julian-klode/apt/compare/1.2.y...julian-klode:for-1.2/locale?expand=1 - Now I'm waiting for travis to check if it actually compiles and passes tests ... [16:45] If it does, I'll build a 1.2.16~rc1 source package or something and put it in the apt 1.2 PPA for testing. [16:46] Hmm, that requires more work: It does not find std::put_time() [16:47] Probably missed the include from another commit :/ [16:48] gtg now, but will be online again in approx 30 mins [17:18] bdmurray: Do we still want to do some upgrade tests with apt 1.2.15 on desktop, or is one month without hiccups on (small) server OK? [17:19] If anyone has not upgraded xenial in a while, now (= soon) is the time to install 1.2.15 from proposed and check that it works for you too :) [17:20] nacc, [17:20] 11/02/2016 17:19:31 - DEBUG:stderr: gbp:error: Upstream tag 'upstream/0.1.0_bzr54' already exists [17:21] smoser: using my branch? [17:21] sort of. [17:21] some local cchanges, but i dont think related [17:21] Otherwise, I'll give the build another week on my server and then go to verification-done (then we basically have 5 weeks of unattended upgrades not messing things up) :) [17:22] smoser: it should only try to tag an upstream (import it at all) if the tag doesn't already exist) [17:22] smoser: if (orig_tarball and [17:22] self.get_tag_reference(upstream_tag_name) is None [17:22] ): [17:22] smoser: ah, is it possible your upstream version doesn't comply with debian? [17:23] smoser: is it an ubuntu only package [17:23] well, this was curtin [17:23] basically upstream snapshots [17:23] no actual upstream releases [17:24] ah ah [17:24] gbp turns ~ to _ [17:24] we don't [17:24] for that particular check [17:24] smoser: change that upstream_tag_name assignment to [17:25] upstream_tag_name = USDGitRepository.git_dsc_commit_tag('upstream/%s' % srcpkg.version.upstream_version) [17:26] or so [17:27] smoser: fyi, usd-clone is incompatible with xgit [17:27] not sure why yet [18:03] smoser: rbasak: http://paste.ubuntu.com/23417200/ [18:04] smoser: i don't think it makes sense to use a cache like MP: #309876 does for the importer, if the builder has a cache [18:05] smoser: i'm not sure what problem the importer cache solves [18:05] regular users will never run the importer, ideally [18:07] nacc, if your argument is "regular users will never use it, so remove it". then we can just delete the whole thing ? [18:07] smoser: delete what whole thing? [18:07] usd-importer. [18:07] as regular users wont use it. [18:07] smoser: i think you're being a bit ridiclous [18:07] there are two use cases [18:07] yes. [18:07] one is the server team maintaining git repositories [18:07] that's the importer's job [18:07] nothign else [18:08] the other is building pacakges using those repositories [18:08] when working with the importer, having the cache of downloaded things is quite useful. [18:08] that is *not* the importer's job [18:08] and your pristine-tar branch changed the behavior from caching into the output directory to downloading into a tmpdir [18:08] smoser: why does your commit mention git and gitwd not existing? they are still present [18:08] smoser: that's not merged [18:08] and currently won't be [18:08] sure. [18:08] thats fine. [18:09] its an option, just like '--lp-user' [18:09] it doesn't make sense to send a MR against master [18:09] when it doesn't apply to master [18:09] which , running on infrastructure would never be needed. [18:09] it does still apply to master. [18:09] its still quite useful [18:09] the commit message is wrong [18:09] it refers to things that aren't true in master [18:10] it makes my re-run using your branch take substantially less time, and saves 51G of download [18:10] the commit message is correct... [18:10] what did you think was not ? [18:10] previously get with the pkg/git/ and pkg/gitwd/ [18:11] that is *not* true in master [18:11] sure.. previously, before this commit [18:11] what? [18:11] before the --dl-cache commit, downloads went into pkg/ [18:11] and then there was a pkg/git and pkg/gitwd [18:11] that is true. [18:11] right? [18:12] and the change is to instead put them to a tempdir or to the --dl-cache dir [18:13] ok, my reading of your commit message is that it suggest there was a change of behavior that you're fixing [18:13] when in fact, you're changing behavior [18:14] it could be *way* clearer :) [18:14] I still don't think a download cache matters *except* for your tests of importing the world [18:15] even importing a single package [18:15] it does. if it fails for some reason. [18:15] master still uses pkg/git and pkg/gitwd, so it'ss till cached in pkg [18:15] firefox or linux for example, are multi-multi-gig downloads [18:16] i think what you're actually doing is suggesting an alternative implementation to what is done in my branch? [18:16] if you have access to dsc files and orig tarballs, put them in a dir and point the thing at it. [18:16] well, due to a change in your branch, i was forced to do *something* [18:16] a branch that is *NOT MASTER* :) [18:16] but what i was doing before was linking these files into the / dir so they'd get used. [18:16] and you are asking to merge to master [18:16] which was much less clean than this [18:17] so this solves cleanly for both cases. [18:17] but is wholly unnecessary in master as it is right now, afaict [18:17] sort of. sort of not. [18:17] yes, that's why i think your commit message is wrong :) [18:17] currently, the directory cannot exist [18:17] you have a good point, just put it in the commit message [18:17] or if it does, it must have git and gitwd/ [18:20] smoser: do you get my point, though? you have two reasons to include this into master, one of which has nothing to do with master itself, but a hypothetical change to the code [18:21] what's interesting is this download cache can't be used by usd-build as currently written, because usd-build's cache is organized [18:21] might not be a big deal [18:22] and, afaict, this only really impacts the importer side, when starting from an empty repository, which will be a rarity [18:22] relative rarity [18:22] and doesn't help the actual empty repository case either, right? [18:23] usd-build's cache is organized ? [18:23] what does that mean ? [18:24] smoser: to make it actually usable (as i need to konw the tarballs in there are good, I also need dsc files, etc.), so we have it organized as .git/build_cache/// [18:24] so I can go find the DSC file in there and see if the hashes of the tarballs match (or if they are even present) [18:26] nacc, http://paste.ubuntu.com/23417260/ [18:26] oh. i see. [18:26] smoser: that's way better, thank you very much [18:26] upstream_version does not seem terribly important there i donthink. [18:27] i think i convinced my self that we need to not do the tmpdir. but by default make it point to the --directory [18:27] smoser: then you won't be able to clean it up, right? [18:27] who is "you" in this scenario ? [18:28] oh. right. yeah. would not cleanup then. [18:28] smoser: the importer, without a dl-cache argument [18:28] which is current behavior [18:28] smoser: which is the default and expected use case [18:28] right, but i'd like to be able to clean it up, if possible [18:28] i think switching to directory would make it impossible? [18:29] tmpdir=$(mktemp -d); usd-import --dl-cache=tmpdir [18:29] ro [18:29] TMPDIR=pkg.d/dldir usd-import --directory=pkg.d pkg [18:29] smoser: if i don't use upstream_version there, then i have to store the .dsc file in upstream_version.dsc (or do filename munging) -- doesn't seem better [18:31] smoser: 'have to' becuase i need to cache the canonical sums for the tarballs somehow [18:32] smoser: i'm not sure i fully understand (given just master), anymore, the usecase for an importer cache. That is, right now, let's say you run the importer on a directroy and pass --no-clean. Then you run it again on the same directory later, it will just pickup where it stopped. So your case is switching directories but minimizing the files to use? [18:32] *to download [18:34] well, that is a use case. [18:34] but as it is right now, if you pass --no-clean [18:34] and you then change the importer and want to use again to do a from scratch [18:34] you: rm -Rf /git* [18:34] and it says "that dir isnt empty" [18:35] rm says that? [18:35] oh you mean if you try to reuse directory iwth the importer [18:35] because the files are there? [18:35] yes, i assume that any sane person doing from scratch imports will [18:36] rm -rf ; mdkir [18:36] *mkdir [18:36] or will use a reasonable directory (previously imported) [18:36] that's why we have the sanity check [18:36] again, this feels like an optimization for 'from scratch' imports [18:36] which i know are annoying because you're doing so many [18:36] but not really a general use [18:37] i mean, obviously, *the* general use -- but not for everyone [18:39] rbasak: one flaw (security?) with the cached DSC model -- what if a pathological user chagnes that file. They will have write access to it. Upload will get rejected (afaict), but it will still succesfully build. I think that's why I was suggesting we always at least pull down the dsc from LP to verify the tarballs against? [18:40] at which point we could drop / altogether, I think [18:41] smoser: and then, if we used that for the cache by default, you'd get your sharing in the importer too; you'd just have to save off the cache before deleting .git [18:42] nacc, i pushed up a different version. [18:43] which i think is generally better, and as is right now cleaner. but i thin it will still complain on --directory= re-use. [18:43] smoser: same MP? [18:43] yeah [18:43] hrm, says updated 1 hour ago [18:44] https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+ref/download-cache ? [18:44] yeah [18:44] taht 1 hour ago is just wrong [18:44] its reading the commit time [18:44] and commit --amend doesnt update that [18:45] hrm, i don't see any changes from the last MP? [18:45] its definitely different read the commit message [18:45] oh i see it now, sorry [18:46]