04:11:48  * madewokherdquit (Remote host closed the connection)
06:36:04  * ender`joined
07:47:55  * jgmdevquit (Quit: Thanks and take care everyone, lets make the world a better place to live :))
07:49:24  * enderjoined
07:49:39  * ender`quit (Read error: Operation timed out)
07:50:45  * ender|quit (Ping timeout: 244 seconds)
08:04:00  * ender|joined
10:41:19  * FearTheCowboyquit
10:48:58  * piscisaureus_joined
11:40:48  * gixquit (Ping timeout: 248 seconds)
11:46:16  * gixjoined
12:44:36  * auroraeosrosejoined
12:46:10  * [[zz]]quit (Ping timeout: 244 seconds)
12:58:37  * [[zz]]joined
13:55:18  * vpovirkjoined
13:59:18  * FearTheCowboyjoined
13:59:28  * FearTheCowboyquit (Changing host)
13:59:28  * FearTheCowboyjoined
14:23:42  * virmitiojoined
14:59:03  <virmitio>vpovirk: on the forks you've been working on, does your package target also auto-increment the version file?
14:59:11  <vpovirk>no
14:59:50  <virmitio>hmm
15:00:48  <virmitio>I need a reasonable and consistent method by which to always increment the versioning of a package, either before or after building it.
15:01:20  <vpovirk>they all use the same sort of define for the package version in version.inc
15:01:31  <virmitio>because I don't want the automation to have even the possibility of constructing the same package+version twice
15:02:26  <vpovirk>I think it's best if you automatically increment, tag, and build
15:02:41  <vpovirk>then it's also clear exactly what git revision was used for every build you do
15:03:09  <virmitio>ok, so do you provide a target in your forks to increment the version?
15:03:13  <vpovirk>no
15:04:16  <auroraeosrose>in order to do that virmitio
15:04:29  <vpovirk>but as I said it all uses the same package-version define in version.inc, so the target would have exactly the same code in every fork
15:04:30  <auroraeosrose>we need a "package version" and a "code version" - do we have that and I"m stupid?
15:04:50  <auroraeosrose>cause it might be the 5th package of openssl - but it's all the same version (if the package got screwed)
15:04:55  <vpovirk>which means it doesn't make sense to me to put it in every fork
15:05:42  <vpovirk>well, my thought was that every automated build would automatically produce a commit and a tag
15:06:05  <vpovirk>so you can get the exact source revision from any build out of git
15:06:39  <vpovirk>which also means it has to successfully push the commit and tag before it even starts the build, since the push could fail..
15:07:37  <vpovirk>also, we have an upstream version
15:08:13  <virmitio>true
15:08:33  <virmitio>ok, with all of that in mind, another procedural question:
15:09:33  <virmitio>when should the automated builds happen? every push to the desired branch(s)? on a static timer? something else?
15:10:06  <vpovirk>good question
15:10:33  <virmitio>a static timer alone should be out of the question, as that could easily result in multiple versions of a package that are completely identical except their version numbers
15:10:44  <vpovirk>one could argue that you should only push to coapp-packages things you intend to be published..
15:10:53  <vpovirk>which would mean every push
15:11:27  <vpovirk>(except those made by the build system itself)
15:11:47  <virmitio>I can easily filter those out
15:12:03  * wwahammyjoined
15:12:45  <vpovirk>the only other option I can think of is that a packager would have to explicitly say that a branch is ready for packaging and trigger the build somehow..
15:13:27  <vpovirk>which doesn't have to be out of band, it could just be some special string in the commit message
15:14:23  <vpovirk>so the question is whether packagers should be pushing things we don't want immediately packaged (which is something I've been doing but would be happy to change)
15:15:38  <virmitio>I can see the merits to both sides on that point. Anyone else want to weigh in on this?
15:16:18  <FearTheCowboy>o_O
15:16:52  <virmitio>auroraeosrose: to your earlier comment, I don't know that we do outside of the "author version" in the package info
15:16:56  <FearTheCowboy>I like the "only push what you wnat published"
15:16:59  <auroraeosrose>hmmmm
15:17:17  <auroraeosrose>I'm thinking of "OMG I SCREWED UP THE PACKAGE" cause you know that never happens...
15:17:27  <auroraeosrose>easy way would be to have a new package version but
15:17:28  * auroraeosroseshrugs
15:17:33  <vpovirk>we'll need another way to let people know we're working on things so we don't duplicate work
15:18:33  <auroraeosrose>I have a better idea
15:18:40  * virmitiois all ears
15:18:41  <auroraeosrose>why dont' we have a branch to use
15:18:46  <auroraeosrose>that is "publish this"
15:18:59  <auroraeosrose>otherwise people can't collaborate on packaging if it's "push to package"
15:19:16  <virmitio>fair
15:19:18  <vpovirk>I think I like that idea
15:20:12  <virmitio>but do we declare the (existing in most places) "CoApp" branch to be push-to-publish, or some other (not yet named) branch?
15:20:14  <auroraeosrose>because we don't want all local dev because some of thes (oh god, php with a million extensions) are going to have collaborators on the packaging code
15:20:28  <auroraeosrose>virmitio: I think at this point you can decide ;)
15:20:35  <auroraeosrose>I like Coapp to keep the coapp stuff
15:20:37  <vpovirk>we'll want to be able to have more than one branch to publish
15:20:55  <auroraeosrose>anything prefixed with publish?
15:21:01  <virmitio>vpovirk: that's not an issue on a per-package basis
15:21:03  <auroraeosrose>publish-coapp publish-php3
15:21:09  <auroraeosrose>whatever?
15:21:14  * auroraeosroseis throwing out ideas
15:21:23  <auroraeosrose>I think at this point virmitio gets to pick - then document it ;)
15:21:46  <virmitio>I'm looking for a basic standard that can be the default on forks that the automation is initially notified about by getting a post-receive notice
15:22:21  <virmitio>auroraeosrose: thanks, I think
15:37:21  <ender>ouch: http://news.slashdot.org/story/12/06/04/1211206/microsoft-certificate-was-used-to-sign-flame-malware
15:38:20  <FearTheCowboy>Yeah, I saw that.
15:39:13  <FearTheCowboy>it seems to implicate an older, exploitable crypto algorithm
15:39:31  <FearTheCowboy>I've wondered when that sort of thing would eventually happen.
15:39:58  <FearTheCowboy>If I was trying to exploit crypto, I'd seek out older cert chains like that too.
15:40:08  <ender>oh
15:40:14  <ender>i haven't read that far yet
15:40:39  <ender>but i was wondering the same thing a few months ago when i was checking the signatures in older MS products
15:41:08  <FearTheCowboy>Hmm.
15:41:30  <FearTheCowboy>we should think about a way to rapidly push certificates into the untrusted cert store.
15:42:30  <virmitio>"I changed my mind, and now I don't really trust that guy"?
15:43:16  <FearTheCowboy>Yeah
15:45:41  <FearTheCowboy>Perhaps we should come up with a way of adding in 'blacklisted/revoked' certificates in feeds.
15:46:17  <FearTheCowboy>that would simplify the 'fetching
15:46:28  <FearTheCowboy>and then we just need to process those entries.
15:46:33  <ender>i wish i requested activation of my terminal server earlier :)
16:21:49  * wwahammyquit (*.net *.split)
16:21:49  * gixquit (*.net *.split)
16:21:49  * piscisaureus_quit (*.net *.split)
16:21:49  * sungamiquit (*.net *.split)
16:31:30  * wwahammyjoined
16:31:30  * gixjoined
16:31:30  * piscisaureus_joined
16:31:30  * sungamijoined
16:33:02  * wwahammyquit (Quit: If you think nobody cares, try missing a few payments)
16:38:09  * auroraeosrosequit (Read error: Connection reset by peer)
17:14:14  * cH40z-Lordjoined
17:19:59  * jgmdevjoined
17:34:19  * wwahammyjoined
17:55:34  <virmitio>I don't recall. Is the only thing in the version.inc files the package version? or did we decide to put other info in there as well?
17:57:30  <vpovirk>I've been putting other stuff in there
17:58:03  <virmitio>k
18:00:09  <virmitio>means I won't be able to alter the file directly from a command prompt
18:00:31  <virmitio>at least, not without a great deal of extra effort
18:03:10  <FearTheCowboy>I was using the version.inc for just the version
18:03:24  <FearTheCowboy>everything else could go in the .autopkg file itself.
18:04:54  <virmitio>FearTheCowboy: vpovirk and I had a conversation a while back about what else might be reasonable to keep in the same place as the version info, such as dependency informaiton. I just couldn't remember the outcome of the conversation.
18:05:18  <vpovirk>I think we wanted the compatibility policy in there but not the dependencies
18:05:38  <virmitio>that could be
18:05:51  <vpovirk>we can't just put dependency information in the .autopkg because then it would be duplicated with .buildinfo, and between different autopkg files
18:07:07  * virmitiois starting to wonder if it would be smarter to go back to only the version in that file and use another include file for the additional information...
18:07:42  <FearTheCowboy>probably
18:34:09  <FearTheCowboy>wwahammy
18:40:25  * Jonny5joined
18:40:25  * Jonny5quit (Changing host)
18:40:25  * Jonny5joined
19:06:50  <virmitio>ok, we have a plan for the versioning
19:06:59  <virmitio>vpovirk, you probably won't like it
19:07:10  * enderquit (Quit: To get as fewest unhappy people as possible, always bully the same ones.)
19:09:49  <virmitio>all packages fall into one of three categories:
19:10:37  <virmitio>1) package version is determined by a version.inc file in the COPKG directory
19:11:03  <virmitio>2) package version is recorded/handled elsewhere
19:11:36  <virmitio>3) package version is unmanaged (as in the case of some limited redistributables that we'll be packaging)
19:11:53  * ender`joined
19:14:14  <virmitio>for cases 1 and 2, it is assumed that the version is updated sometime during the run of 'ptk package'. The details of how this happens do not matter, nor do we care. If a maintainer wishes to be able to produce .msi files without increasing the version number, they may implement a variable to be passed via the command-line which will skip the version update, but the default action of the
19:14:26  <virmitio>'package' target should always be to update the version information
19:16:32  <virmitio>in case 2, an additional target named 'commit-version' must be included in the .buildinfo file which will generate a git commit containing all necessary updated version information. This target is expected to add any necessary files and perform the commit, including any appropriate message, but is not to perform a push.
19:16:49  <virmitio>questions?
19:24:26  <wwahammy>TL;DR
19:32:20  <vpovirk>in case 1, is the version updated before or after creating the package?
19:34:10  <virmitio>either. However, if the push fails, the packages that are built will not be published to the feed.
19:43:27  <vpovirk>if it's before, I would worry that the versions in git won't match up with the versions built by the automation, unless the change is also pushed and tagged before the build
19:44:05  <vpovirk>my understanding was that as soon as you build the same version twice, things can be messed up, and not pushing before the build could lead to that
19:45:58  <vpovirk>if it's after, that would also be confusing because whenever the build automation pushes a version update, that revision will be BEFORE the revision that will eventually be used to build that new version, if a package with that number is ever published at all
19:48:37  <virmitio>the current expectation of the lifecycle is similar to thus, where each step only occurs if the previous step succeeded: pull --> build --> local archive --> push version --> publish to feed
19:49:48  <vpovirk>I'm ok as long as the version you build is the same as the version you push, and as long as you won't run into problems because you built the same version twice
19:50:11  <virmitio>the early forks were designed to update the version file at the start of the 'package' target, so the resulting package built would have the same version as that being pushed back to the repo
19:51:24  <virmitio>I can keep the local archive isolated from observation, which will keep the automation from going nuts if it builds the same version more than once. My biggest concern is preventing multiple builds of the same version from making it out into the wild
19:53:24  <vpovirk>also: this essentially means you have a self-modifying ptk script
19:53:49  <virmitio>I'm ok with that
19:53:54  <vpovirk>it means my targets in package will be foo-1.0.0.1-x86.msi
19:54:04  <vpovirk>while foo-1.0.0.2-x86.msi will be built
19:54:11  <vpovirk>so the target will fail
19:54:41  <virmitio>hmm...
19:55:48  <virmitio>need to ask FearTheCowboy about that, as it worked fine in the past
19:56:02  <virmitio>for the moment, however, I need to eat something
19:56:04  <vpovirk>maybe you didn't have targets in your package
19:56:21  <virmitio>that could be
19:56:21  <vpovirk>or maybe it incremented after building
19:56:36  * virmitiois grabbing lunch quick, and will return shortly...
20:09:03  <virmitio>and I'm back
20:09:32  <ender`>does anybody know of a program that would make automatic backups of my USB pendrives?
20:09:38  * Jonny5quit (Read error: Connection reset by peer)
20:15:35  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:20:47  * vpovirkquit (Remote host closed the connection)
21:59:46  * piscisaureus_joined
21:59:55  * madewokherdjoined
22:09:26  * ender`quit (Quit: What if there were no hypothetical questions?)
22:15:12  * jgmdevquit (Quit: Thanks and take care everyone, lets make the world a better place to live :))
22:49:35  <FearTheCowboy>yo
23:04:20  * cH40z-Lordquit (Quit: Wenn 2 im Raum sind, 3 raus gehen, dann muss einer zur├╝ckkommen, dass keiner mehr da ist.)
23:26:26  * virmitioquit (Quit: So long and thanks for all the fish.)
23:49:43  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)