| pitti | Good morning! | 03:32 |
|---|---|---|
| pitti | Laney: in the light of bug 1478623 I guess it's prudent to set a force-badtest udisks2? | 04:20 |
| ubottu | bug 1478623 in linux (Ubuntu) "Kernel oops - blk_update_request: I/O error when running udisks2 force_test_removal test" [Undecided,Confirmed] https://launchpad.net/bugs/1478623 | 04:20 |
| infinity | pitti: Probably, yeah. | 04:42 |
| pitti | # kernel regression: https://launchpad.net/bugs/1478623 | 04:43 |
| ubottu | Launchpad bug 1478623 in linux (Ubuntu) "Kernel oops - blk_update_request: I/O error when running udisks2 force_test_removal test" [Undecided,Confirmed] | 04:43 |
| pitti | force-badtest udisks2/2.1.6-1 | 04:43 |
| pitti | infinity: ^ do these two lines look correct for the hints file? | 04:44 |
| pitti | (still not very acquainted with them, thus double-checking) | 04:44 |
| infinity | pitti: Assuming the version is correct, sure. | 04:44 |
| pitti | ack, committed | 04:45 |
| pitti | that should unblock glib2.0 | 04:45 |
| infinity | And gtk. | 04:45 |
| infinity | And a few other things. | 04:45 |
| hyperair | why does a dropped wifi connection lead to chromium losing connection to its main instance and attempting to open a new one? | 05:24 |
| dholbach | good morning | 07:00 |
| flexiondotorg | dholbach, ubuntu-mate-artwork 0.4.11 is currently sitting in wily-proposed. Can you move it to release? | 07:20 |
| dholbach | no | 07:20 |
| dholbach | that's done automatically, using this process: https://wiki.ubuntu.com/ProposedMigration | 07:20 |
| flexiondotorg | dholbach, OK. Thanks. | 07:21 |
| Laney | pitti: hiya - I thought you might want to upload and just skip that one | 08:03 |
| Laney | and WB! | 08:03 |
| pitti | Laney: thanks! | 08:04 |
| pitti | Laney: see scrollback, I pushed a hint for udisks2 now | 08:04 |
| Laney | yes I see | 08:04 |
| Laney | but perhaps it would be good to instead run the rest of the testsuite minus that one | 08:05 |
| Laney | did you have a good holiday? :) | 08:05 |
| pitti | Laney: yes, it was very recreative; although quite exhausting to climb the mountains with a trekking bike and lots of luggage :) (but we made it!) | 08:07 |
| pitti | Laney: ah, skipping that test on i386, could do that too | 08:08 |
| pitti | Laney: apart from the bugs you filed, how did the cloud stuff hold up? | 08:10 |
| pitti | Laney: did you have to do a lot of manual juggling? | 08:10 |
| Laney | pitti: Not so much - quite a few stuck instances but it wasn't generally apparent to me what had happened | 08:12 |
| Laney | I didn't analyse all of the tmpfails though | 08:12 |
| pitti | Laney: ah, I'll do that again this week; I got them to zero before I left | 08:14 |
| pitti | indeed, there are a few now | 08:14 |
| Laney | oh, even more since I looked (yesterday?) | 08:14 |
| Laney | pitti: debci's test-deps diff was very useful in filing that udisks2 bug | 08:15 |
| Laney | it basically fingered kernel or glib | 08:15 |
| pitti | Laney: indeed, I really like that | 08:16 |
| pitti | infinity: FYI, I fixed your linux hint (sorry for touching your file) | 08:39 |
| ogra_ | hmpf | 08:40 |
| ogra_ | infinity, didnt you say fan doesnt use dnsmasq anymore ? seems it still installs it | 08:40 |
| ogra_ | apw, ^^^ | 08:41 |
| ogra_ | (it makes the snappy images fail if i dont add the user manually, but i want to be sure it is correct to add it) | 08:42 |
| apw | ogra_, it should use dnsmasq-base not dnsmasq | 08:44 |
| ogra_ | ok, then the user creation is fine, thanks | 08:44 |
| * ogra_ adds | 08:44 | |
| apw | ogra_, thanks | 08:45 |
| doko | infinity, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7730303 | 09:10 |
| doko | seb128, was the glibmm2.4 package converted with your script, or done by hand? | 09:25 |
| seb128 | doko, I'm poking around doing a script and used it for testing | 09:26 |
| doko | seb128, missing conflicts and replaces | 09:29 |
| seb128 | doko, oh, good point, thanks ;-) | 09:29 |
| doko | I'm collecting all explicit transitions at https://wiki.ubuntu.com/GCC5 | 09:30 |
| doko | seb128, and extra points for identifying that libsigc++ needs a bump too, and then adjusting the b-d in glibmm2.4 ;) | 09:31 |
| cjwatson | doko: are you asking infinity that because of the bogus dep-wait? | 09:33 |
| doko | cjwatson, yes | 09:33 |
| cjwatson | doko: then I don't know why you're asking infinity, because that's a Launchpad team thing, and it'll be fixed in the next launchpad-buildd rollout | 09:33 |
| cjwatson | (it's my fault) | 09:34 |
| doko | ahh, ok | 09:34 |
| doko | when is it scheduled? | 09:34 |
| cjwatson | doko: not scheduled yet, hopefully soon. but you have no reason to be waiting for it - if you know the deps are satisfied, just retry manually | 09:34 |
| cjwatson | doko: I mean, the only difference in this case would be that the build would fail rather than dep-wait | 09:35 |
| cjwatson | so you'd have to retry anyway | 09:35 |
| doko | ok, something different too, investigating | 09:36 |
| doko | The following packages have unmet dependencies: | 09:36 |
| doko | sbuild-build-depends-unity-scope-click-dummy : Depends: libunity-scopes-dev (>= 0.6.7~) but it is not going to be installed | 09:36 |
| cjwatson | doko: yes, that means the build-dependency is uninstallable for some reason, apt doesn't say why | 09:36 |
| cjwatson | (perhaps uninstallable in combination with other build-deps) | 09:36 |
| cjwatson | Logan: apologies for the exceptionally cryptic failure from gem2deb. The problem was that ruby2.2 was in universe; I've moved it to main, which should help. | 10:12 |
| cjwatson | Logan: however, gem2deb is still going to run into several problems in Launchpad with support for the new build profiles syntax. We should get these sorted out soonish ... | 10:13 |
| doko | xnox, infinity: https://bugs.launchpad.net/bugs/1348954 | 10:39 |
| ubottu | Launchpad bug 1348954 in python3-stdlib-extensions (Ubuntu Trusty) "update Python3 for trusty" [Undecided,Confirmed] | 10:39 |
| doko | the (apparently) only Python3 related change seems to be from https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1326707 | 10:40 |
| ubottu | Launchpad bug 1326707 in ubiquity (Ubuntu) "Ubiquity does't start, hangs in "/usr/lib/ubiquity/bin/ubiquity", line 426, in acquire_lock, test_debconf.stdout.readline()" [Critical,Fix released] | 10:40 |
| doko | wondering if backporting this to trusty would help | 10:40 |
| === MacSlow is now known as MacSlow|lunch | ||
| ogra_ | cjwatson, do our non native armhf PPAs still use qemu-user-static ? | 12:13 |
| * ogra_ tries to re-vivie rootstock for local image building and runs into reallyy weird dependency issues on armhf | 12:13 | |
| ogra_ | *re-vive | 12:13 |
| cjwatson | ogra_: Yes | 12:20 |
| cjwatson | ogra_: Assuming you mean our virtualised armhf builders | 12:20 |
| ogra_ | yeah | 12:20 |
| ogra_ | hmm, then the issue must be on my side | 12:21 |
| ogra_ | (assuming someone would have noticed if they fail to bootstrap :) ) | 12:21 |
| cjwatson | Well, the chroots are only refreshed periodically. | 12:22 |
| cjwatson | But livefs builds would catch a bootstrap failure. | 12:22 |
| ogra_ | yeah, and you your surely notice if python3 isnt installable :) | 12:22 |
| ogra_ | http://paste.ubuntu.com/11953230/ | 12:23 |
| ogra_ | (happens with -updates in the sources.list as well) | 12:23 |
| cjwatson | Hard to guess from that; you'll have to do the usual drilling down you need to do to get a sensible error out of apt. | 12:23 |
| ogra_ | oh, verbosity in debootstrap helps a little :) | 12:23 |
| ogra_ | I: Configuring ureadahead... | 12:24 |
| ogra_ | W: Failure while configuring base packages. This will be re-attempted up to five times. | 12:24 |
| ogra_ | W: See //debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/python3_3.4.3-1_armhf.deb is at fault) | 12:24 |
| ogra_ | i guess thats it | 12:24 |
| cjwatson | What does the log say about python3? | 12:25 |
| ogra_ | Selecting previously unselected package python3. | 12:25 |
| ogra_ | dpkg: regarding .../python3_3.4.3-1_armhf.deb containing python3, pre-dependency problem: | 12:25 |
| ogra_ | python3 pre-depends on python3-minimal (= 3.4.3-1) | 12:25 |
| ogra_ | python3-minimal is not installed. | 12:25 |
| ogra_ | hmm, wow ... running qemu-debootstrap manually doesnt expose that issue | 12:32 |
| ogra_ | oh, it does ... it was just slower | 12:32 |
| cjwatson | ogra_: Can you pastebin the whole log? | 12:32 |
| ogra_ | http://paste.ubuntu.com/11953401/ | 12:33 |
| ogra_ | (exited with ctrl-c ) | 12:33 |
| ogra_ | host is trusty if that has any influence | 12:34 |
| soee | guys in available drivers we have nvidia-346 but there is no such driver version on nvidia'a site: http://www.nvidia.com/object/unix.html any idea why ? | 12:35 |
| === _salem is now known as salem_ | ||
| cjwatson | ogra_: All the "package not in database" warnings are suggestive; that seems to indicate that setup_available isn't working for some reason, which would prevent debootstrap's Pre-Depends resolution from working | 12:39 |
| ogra_ | hmm, could that be realted to using wilys debootstrap on trusty (i wouldnt know why) | 12:40 |
| cjwatson | ogra_: I wouldn't have thought so ... could you pastebin </path/to/chroot>/var/lib/dpkg/available ? | 12:42 |
| ogra_ | cjwatson, empty | 12:44 |
| ogra_ | ogra@anubis:~/Devel/branches/project-rootstock-ng$ ls -lh test/var/lib/dpkg/available | 12:45 |
| ogra_ | -rw-r--r-- 1 root root 0 Jul 28 14:42 test/var/lib/dpkg/available | 12:45 |
| ogra_ | i used: sudo qemu-debootstrap --arch armhf vivid test http://localhost:9999/ubuntu-ports ... (happens also without package proxy) ... nothing fancy | 12:47 |
| cjwatson | ogra_: I'll have a look locally | 12:50 |
| cjwatson | https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1450980 also - I suspect this is something specific to the qemu path in some way | 12:50 |
| ubottu | Launchpad bug 1450980 in debootstrap (Ubuntu) "Python 3.4.3 package fails to install with deboostrap on armhf" [High,Confirmed] | 12:50 |
| ogra_ | oooh, since may already ! | 12:50 |
| ogra_ | thanks ! | 12:51 |
| * ogra_ adds --variant=minbase for now ... | 12:51 | |
| ogra_ | hmm | 12:51 |
| ogra_ | though ... why dont i just use an ubuntu-core tarball for the outer chroot | 12:51 |
| * ogra_ will ponder over that a little :) | 12:52 | |
| === MacSlow|lunch is now known as MacSlow | ||
| === attente_ is now known as attente | ||
| ogra_ | cjwatson, just to confirm, --variant=minbase helps indeed | 12:59 |
| cjwatson | ogra_: Ah, I see the bug | 13:00 |
| ogra_ | yay | 13:00 |
| cjwatson | ogra_: https://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=e24e4b006736734e20cc66398099b94dd4e5cb90 | 13:34 |
| cjwatson | (tested, works) | 13:35 |
| ogra_ | whee ! | 13:35 |
| cjwatson | I've uploaded that to unstable, can sync it later | 13:35 |
| ogra_ | yeah, i dont mind to use minbase for the outer chroot (and the inner ones dont expose it interestingly .... probably because not --foreign) | 13:36 |
| cjwatson | this bug is entirely about --foreign | 13:36 |
| ogra_ | yep | 13:36 |
| ogra_ | thanks for the quick fix !! | 13:36 |
| cjwatson | np | 13:36 |
| smoser | hey. anyone seen anything like this: http://paste.ubuntu.com/11953680/ | 13:45 |
| smoser | when i install (dpkg -i) a cloud-init deb, i get quite a long pause after | 13:45 |
| smoser | cloud-config.target is a disabled or a static unit, not starting it. | 13:45 |
| smoser | the install of that took 30 seconds! | 13:45 |
| smoser | the long time is on a wait for /var/lib/dpkg/info/cloud-init.postinst | 13:48 |
| smoser | maybe this is what slangasek alluded to? i think my services are getting started or re-started on dpkg -i. | 13:50 |
| smoser | probably something i've done wrong in my packaging.. | 13:50 |
| smoser | any cluees ? | 13:50 |
| === Malsasa_ is now known as Malsasa | ||
| smoser | hey, wondering how someone would suggest fixing https://bugs.launchpad.net/curtin/+bug/1477795 | 15:07 |
| ubottu | Launchpad bug 1477795 in curtin "fix tox with dependency on python-parted" [Undecided,New] | 15:07 |
| smoser | basically i want to run tox, but python-parted nto available in tox. | 15:07 |
| smoser | er.. not available in pypi/ | 15:08 |
| doko | seb128, slangasek : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790756 | 15:08 |
| ubottu | Debian bug 790756 in release.debian.org "transition: libstdc++6 cxx11" [Normal,Open] | 15:08 |
| seb128 | doko, thanks | 15:09 |
| teward | has anyone seen firefox crashes in the latest kernel on 14.04? Firefox crashes randomly since a couple updates ago, nothing conclusive in Firefox, but it seems i'm not the only one impacted... | 15:10 |
| infinity | pitti: "fixed"? | 15:15 |
| pitti | infinity: bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/ | 15:16 |
| infinity | ogra_: It doesn't use dnsmasq, it uses dnsmasq-base, very different. | 15:16 |
| ogra_ | infinity, yeah, i only needed to know if the user creation is needed, all fixed now | 15:16 |
| infinity | pitti: Oh, no, it was force-skiptest intentionally to get linux itself in. | 15:16 |
| infinity | pitti: But yeah, until we fix that broken apparmor test, it should *also* be badtest. :P | 15:17 |
| pitti | infinity: doesn't badtest imply skiptest? | 15:17 |
| infinity | pitti: badtest is for a specific package/version test. skiptest is to skip *all* tests on a package/version's migration. | 15:17 |
| infinity | pitti: linux wasn't the only test stopping linux from migrating. | 15:18 |
| pitti | infinity: ah, ok | 15:18 |
| jderose | infinity: today's 14.04.3 64bit desktop ISO is installing swimmingly... do i have you to thank for that? :) | 15:18 |
| infinity | pitti: And the other failures are valid failures in their own right (ie: badtesting a test that is holding a package in proposed correctly is, well, bad) | 15:18 |
| infinity | jderose: By "today's", do you mean .1? | 15:18 |
| infinity | jderose: Cause I'd expect .2 to have regressed again, and if it hasn't, I'll be SUPER CONFUSED. | 15:19 |
| jderose | infinity: er, well what ever "current" is pointing to, sha1sum 5f03d86340d83dce4418a12409051914b5c03ae0 | 15:19 |
| infinity | jderose: That's .1 indeed. | 15:20 |
| infinity | jderose: So, yeah. You won't be happy with the reason, though, since you were one of the people asking for a new python. :P | 15:20 |
| jderose | infinity: what was the issue, btw? | 15:20 |
| infinity | jderose: New python3.4 broke ubiquity. That .1 build is a one-off with only python rolled back. | 15:20 |
| jderose | gotcha, thanks | 15:22 |
| infinity | Oh, but doko may have found a ubiquity cherry-pick to fix it. | 15:23 |
| doko | infinity, see backlog, proposing a backport for ubiquity | 15:23 |
| infinity | doko: I can test that a bit later. | 15:23 |
| infinity | doko: Thanks! | 15:23 |
| infinity | doko: The description (hand on PIPE to debconf-communicate) definitely looks like the regression I'm seeing on the ISOs, so this is promising. | 15:24 |
| infinity | doko: I didn't think to go looking in bzr because I didn't expect 3.4.0 -> 3.4.3 to have this sort of behaviour change, though. | 15:24 |
| infinity | doko: What are the odds of this negatively affecting other packages? | 15:25 |
| doko | infinity, odds ... well, had the test rebuild of trusty main without seeing any issues | 15:28 |
| doko | and I uploaded a new package to fix a regression in the tests, introduced by an openssl security update | 15:29 |
| smoser | is it known that http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-w-tracking-bug-tasks.html#ubuntu-server does not seem to be refreshing | 16:05 |
| smoser | ? | 16:05 |
| smoser | footer shows: Thursday, 09. July 2015 03:47 UTC | 16:05 |
| rbasak | http://reqorts.qa.ubuntu.com/reports/ubuntu-server/merges.html is the same | 16:06 |
| rbasak | I was going to file an RT but haven't yet. | 16:06 |
| smoser | rbasak, do you want to / could you do that ? | 16:13 |
| rbasak | ack | 16:13 |
| dobey | slangasek, infinity: either of you around and got a couple minutes to answer some packaging questions? | 20:51 |
| infinity | dobey: Depends on the complexity of the question(s). | 20:59 |
| dobey | infinity: so, we are writing some go code now, and we are making use of some tools, which we currently need to pull into our source tree, build locally, and run from there, to process coverage reports and such. i'm thinking it would be better to have these tools packaged in the archive, and we just build-dep on them. | 21:01 |
| dobey | infinity: however, these tools have no upstream release tarballs as such, and are basically unversioned (outside of git commit hashes). so i'm wondering what the best practice would be to package such things as debs | 21:01 |
| infinity | dobey: Cut an upstream tarball, call it version 0.$date, mention the commit hash you checked out in debian/changelog, and how the tarball is created in debian/README.source, bonus points for a get-orig-source target in debian/rules that does the work for you, so you don't have to do it by hand every time. | 21:05 |
| dobey | hmm, ok. thanks | 21:07 |
| infinity | dobey: And, for the love of FSM, exclude .git when building the tarball. ;) | 21:07 |
| dobey | yeah. i wish git had an "export" command that worked like bzr does | 21:08 |
| infinity | dobey: git-archive(1) | 21:08 |
| infinity | Because using "export" like bzr, svn, and cvs would have been not hipster enough. | 21:09 |
| infinity | dobey: Is this going to be one of those "build twice, once with coverage bigs enabled, once not, then test" cases? | 21:10 |
| dobey | infinity: nah, go coverage seems to be smart enough to not need that at least | 21:11 |
| infinity | dobey: If so, then you're also looking at, yes, making these build-deps and then, of course, the side-effect that you might need MIRs. | 21:11 |
| infinity | dobey: If it can be done post-build without rebuilding, you could do it as dep-8 tests, which might be more pleasant. | 21:11 |
| infinity | We allow dep-8 in main to depend on universe, since it's not about things being self-contained at build time anymore. | 21:12 |
| dobey | well, we need coverage during the builds for the things using it, because CI train doesn't handle dep-8 for getting the coverage | 21:12 |
| dobey | so yeah, we'll probably need some MIRs for stuff at some point | 21:13 |
| infinity | dobey: Fair. Well, packaged beats embedded in each source anyway, so you're on the path of lesser evil. | 21:13 |
| dobey | yeah | 21:13 |
| infinity | dobey: If upstream does have version numbers, of course, just not tarball releases, amend my 0.$date recommendation with $version.$date or whatever. | 21:14 |
| infinity | dobey: Key being that you need $date there because lolgit. Hashes don't sort. :) | 21:14 |
| dobey | yeah. my experience with github though is that people don't tend to do version numbers, especially for things written with go | 21:15 |
| === salem_ is now known as _salem | ||
| dobey | one tends to be lucky if they even document licenseing and copyright info | 21:15 |
| infinity | dobey: Yeah, my experience with the github world has been pretty rough. | 21:16 |
| infinity | dobey: The licensing thing being my biggest complaint. There seems to be this view that "it's on teh internets, so it's clearly all free, so who cares", and it's going to bite someone, really hard. I'm just waiting for that car-sized other shoe to drop. | 21:17 |
| dobey | yeah | 21:17 |
| infinity | dobey: Pretty much all my other "github style development" complaints stem from the licensing thing, I suspect. No one thinks it's a big deal to give you a binary without exact matching source, or embed random source without provenance, etc, etc, if they don't care that there might be a license preventing such silliness. | 21:20 |
| dobey | yeah | 21:20 |
| infinity | dobey: I'm not the GPL's biggest fan, but I will admit that it accidentally led to some very sane development practices as a nice side effect. | 21:20 |
| infinity | Well, probably not accidentally. I'm sure that was half the point, and "freedom" was the excuse. Either way, it worked out for a decade or two. | 21:21 |
| dobey | yeah, the "anything using this code, must be relaesed under the same license" license, is a good way to tell people that their code is under your license | 21:21 |
| infinity | And now a whole new generation seems intent on learning all the same lessons again by making all the same mistakes again. :( | 21:21 |
| dobey | yeah, this new found "lets deploy static binaries everywhere" thing is not likely to end nicely | 21:22 |
| infinity | It works great for people who have the infrastructure in place to do it properly. | 21:22 |
| infinity | Which is, basically, Google. And Facebook. And pretty much nobody else who thinks they're being clever by trying to do it the same way. | 21:22 |
| dobey | yeah | 21:23 |
| infinity | Google's infra is very much designed to deal with that in a sane way, though. A line changes, the world rebuilds, re-tests, and redeploys. | 21:23 |
| infinity | Which is a far cry from the "throw a blow in docker and ignore it" crowd. | 21:24 |
| infinity | s/blow/blob/ | 21:24 |
| dobey | i'm sure they tend to have more vetting of licenses for "opern source" things they throw in their infrastructure | 21:25 |
| dobey | versus the "ooh i found this code on github and didn't read anything and just threw it in docker" types | 21:25 |
| infinity | They read licences very carefully, yes. :P | 21:25 |
| infinity | So they can weed out ones that the don't love to bits (like AGPL). | 21:26 |
| infinity | s/the /they / | 21:26 |
| infinity | Cause it turns out that building your prorietary web empire on the AGPL might not be ideal. | 21:26 |
| dobey | yeah | 21:27 |
| dobey | i've dealt with agpl enough in my life already :) | 21:27 |
| dobey | hrmm, is there a decent way to get the timestamp of the last commit in a remote repository with git? | 21:28 |
| dobey | my search-fu isn't turning up any useful info so far | 21:28 |
| infinity | git show | grep ^Date, but there must be something less icky. | 21:29 |
| dobey | i guess i can't do "git log" on a remote repo though? | 21:30 |
| infinity | dobey: Not sure why remote matters, I assume your first step is a shallow clone, so you have the bits locally to tarball from. | 21:30 |
| jtaylor | looking through .git/FETCH_HEAD might work | 21:30 |
| jtaylor | after a fetch | 21:31 |
| jtaylor | if you have a specific branch in mind just FETCH_HEAD | 21:31 |
| dobey | well i was trying to avoid cloning; git archive supports archiving from the remote it seems | 21:31 |
| infinity | Ahh. | 21:31 |
| dobey | i guess i might have to write a bit more shell to clone and then make the tarball though, so i can get the useful bits of info about the repo | 21:32 |
| dobey | or just create a bzr import on lp, and then just use bzr to do it | 21:32 |
| jtaylor | oh without a local clone | 21:33 |
| jtaylor | if the repo is on github you could use svn ;) | 21:33 |
| dobey | hmm, i guess that's true | 21:34 |
| infinity | Just clone. :P | 21:34 |
| infinity | It's not world-ending. | 21:34 |
| infinity | dobey: --depth might help with bandwidth concerns. | 21:36 |
| jtaylor | --mirror should avoid the local checkout if disk is the problem :) | 21:36 |
| dobey | yeah, but i was just trying to be clever by comparing timestamps for creating new tarballs | 21:36 |
| dobey | no, storage and bandwidth aren't a concern really; just trying for clever optimizations :) | 21:37 |
| infinity | dobey: Doesn't look like there's a way to view remote history (without a web viewer that does it for you or some such) | 21:39 |
| dobey | yeah, that's what i'm finding too | 21:39 |
| infinity | dobey: So your best speed optimisation would be clone --depth=1 --bare, and then archive from there. | 21:39 |
| infinity | dobey: Or skip --bare and archive, and just let it do the HEAD checkout and run tar yourself. | 21:40 |
| infinity | Gets you the same result. | 21:40 |
| dobey | i guess i'll have to clone. idea was to make the tarball timestamp match the last commit, rather than just time(NULL) | 21:41 |
| dobey | well, and to implement the watch rule to check for a new version | 21:42 |
| infinity | $ date +%s -d "$(git show | grep ^Date | sed -e 's/^Date: *//' -e 's/ *+.*//')" | 21:44 |
| infinity | 1432924833 | 21:44 |
| infinity | I hate myself a little bit for that. | 21:45 |
| jtaylor | isn't there some pretty command for timestamp? | 21:45 |
| dobey | anyway, gotta run now. i'll look at building a couple packages later | 21:45 |
| dobey | haha | 21:45 |
| dobey | git log -1 --prety=format:%cd ? | 21:45 |
| jtaylor | %at: author date, UNIX timestamp | 21:45 |
| infinity | ct | 21:47 |
| infinity | git log -1 --date=short --pretty=format:%cd | 21:49 |
| infinity | That comes out almost usable. | 21:49 |
| dobey | but nothing to give 20150725103456 style | 21:49 |
| infinity | Anyhow, too much time. | 21:49 |
| infinity | .. spent on this. | 21:49 |
| dobey | yeah, time for me to go anyway. | 21:49 |
| dobey | later :) | 21:49 |
| dobey | thanks again infinity | 21:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!