00:04:35  * vpovirkquit (Remote host closed the connection)
00:16:42  * jgmdevquit (Remote host closed the connection)
01:04:18  * gixquit (Ping timeout: 255 seconds)
01:08:30  * gixjoined
01:20:03  * auroraeosrosequit (Quit: Leaving.)
02:58:18  * madewokherdjoined
04:06:38  <madewokherd>you know, 7zip can extract .msi files
04:06:48  <madewokherd>so maybe if I built on that I'd just have to decode the tables
04:07:48  <madewokherd>ah, no, it doesn't seem to be available as a shared library
04:10:41  <madewokherd>and I am definitely not maintaining compatibility with any msi exports that involve sql
04:16:59  <madewokherd>and libgsf probably does about as much as 7z can
04:23:18  * Kitten_Basketjoined
04:25:03  <madewokherd>also I think the summary information is different from the database stuff..
04:42:31  * madewokherdquit (Remote host closed the connection)
04:43:23  * [[zzz]]joined
04:47:08  * [[zz]]quit (Ping timeout: 264 seconds)
04:49:46  * Gunniquit (Quit: now entering real-life...)
04:51:45  * Gunnijoined
04:59:00  * [[zzz]]changed nick to [[zz]]
05:11:49  * Kitten_Basketquit (Quit: Kitten_Basket)
06:47:48  * ender`joined
08:30:08  * TReKiEquit
08:35:42  * TReKiEjoined
10:16:03  * Scotis_quit (Read error: Connection reset by peer)
12:18:09  * auroraeosrosejoined
12:51:25  * piscisaureus_joined
13:30:49  * piscisaureus_quit (Read error: Connection reset by peer)
13:31:25  * piscisaureus_joined
13:33:04  * piscisaureus_quit (Read error: No route to host)
13:33:10  * piscisaureus_joined
13:34:31  * piscisaureus_quit (Read error: Connection reset by peer)
13:39:19  * vpovirkjoined
14:04:58  * piscisaureus_joined
14:10:50  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
14:12:40  * piscisaureus_joined
14:20:27  * piscisaureus_quit (Ping timeout: 246 seconds)
14:21:40  * piscisaureus_joined
14:28:07  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
14:30:40  * piscisaureus_joined
14:32:32  * piscisaureus_quit (Client Quit)
14:34:30  * piscisaureus_joined
14:37:24  * Jonny5joined
14:38:32  * piscisaureus_quit (Read error: Connection reset by peer)
14:42:47  * virmitiojoined
14:43:31  * sungami_quit (Ping timeout: 264 seconds)
14:46:12  * piscisaureus_joined
14:57:26  * auroraeosrosequit (Read error: Connection reset by peer)
14:59:23  * auroraeosrosejoined
15:14:52  * piscisaureus_quit (Read error: Connection reset by peer)
15:15:30  * piscisaureus_joined
15:37:19  * sungamijoined
15:37:20  * sungamiquit (Changing host)
15:37:20  * sungamijoined
16:28:03  * piscisaureus_quit (Read error: Connection reset by peer)
16:30:31  * Jonny5quit (Read error: Connection reset by peer)
16:31:10  * piscisaureus_joined
16:32:10  * GarrettS-MSFTjoined
16:32:10  * GarrettS-MSFTquit (Changing host)
16:32:10  * GarrettS-MSFTjoined
16:32:10  * FearTheCowboyquit (Disconnected by services)
16:32:22  * GarrettS-MSFTchanged nick to FearTheCowboy
16:52:14  * Jonny5joined
16:52:15  * Jonny5quit (Changing host)
16:52:15  * Jonny5joined
17:16:33  * auroraeosrose1joined
17:17:25  * auroraeosrosequit (Disconnected by services)
17:19:35  * auroraeosrose1changed nick to auroraeosrose
17:19:43  * auroraeosrosequit (Changing host)
17:19:43  * auroraeosrosejoined
17:29:40  * jgmdevjoined
18:04:17  * FearTheCowboyis thinking outloud... What if we changed package formats so that the bootstrapper was the container for the package (ie, we used a PE EXE and put the entire package payload as a resource in the EXE itself)... and then renamed the .EXE to .COM (uh, for COMponent, yeah, that's it...)
18:05:03  <FearTheCowboy>it's still recognized by the shell and command line.
18:05:27  <FearTheCowboy>hmmm: openssl-1.0.5.9-x86-123131312311.com
18:05:34  <FearTheCowboy>still looks weird to me.
18:05:51  * virmitiothinks more explaining is in order, else large flammable object may become involved in the decision-making process.
18:06:01  <ender`>what about group policy installs then?
18:06:13  <FearTheCowboy>ender -> goooood question.
18:06:54  <virmitio>are why is this a consideration now? or is it just more frustration with msi?
18:07:07  <ender`>(also, do not put anything big as a resource - winzip selfextractor used to do that, and it caused great pain for large archives)
18:07:57  <FearTheCowboy>I have a meeting today with many folks across the company regarding "packages" ... .MSI files might not be supported out-of-the-box on Windows Server Core (or Windows Embedded)
18:08:38  <FearTheCowboy>They have strongly related goals for packages as CoApp does, they want to combine efforts and have a "one-true-package-format-to-rule-them-all" ...
18:08:57  * FearTheCowboyis optimistic. And excited if we can have a lot of what coapp does put directly into the OS.
18:09:19  <auroraeosrose>oook
18:09:21  <FearTheCowboy>but, whatever it is, it has to have the possibility to bootstrap on backlevel OSes (so, no new extension)
18:09:39  <FearTheCowboy>'frictionless' is one of my top priorities.
18:09:41  <auroraeosrose>I'd say - com can be tweaked to be that format extension I suppose
18:09:51  <auroraeosrose>but I'd really think that should be a separate container
18:09:58  <auroraeosrose>we will have different container types yes?
18:10:05  <FearTheCowboy>likely, yes.
18:10:31  <FearTheCowboy>Certainly CoApp will still extend the base format, and provide unification of non-OS packages (ie, gems, npms, etc)
18:10:47  <FearTheCowboy>Yeah, the .COM extension isn't really used these days, and gets treated as an EXE by the system
18:10:55  <FearTheCowboy>which is pretty tasty.
18:10:58  <auroraeosrose>I'd say we just have an msi format and then our own "com" coapp packages
18:11:07  <auroraeosrose>good enough ;)
18:11:45  <FearTheCowboy>Well, if the other folks adopt the common package format, and provide for an extensible metadata in the files, anything they don't do, we can.
18:11:53  <virmitio>so that leaves us with 'msi' (which sounds like a non-starter), 'exe' (which everything under the sun is wary of executing), 'com' (which most people won't recognize and therefore will be automatically wary of), and 'cab' (which I've never tried using for anything practical)
18:12:33  <FearTheCowboy>MSI could be used just for it's ability to smuggle in the bootstrapper EXE and run it. (like we do today), but not use it for any of it's MSI stuff.
18:12:54  <vpovirk>cab isn't an executable format
18:13:09  <auroraeosrose>I vote com and keep our msi format (dont' we still need that for faux pas?)
18:13:11  <FearTheCowboy>the built-in tools could be made to recognize that kind of MSI and treat it differently
18:13:35  <auroraeosrose>eh - at this point this is very future soo
18:13:37  <FearTheCowboy>We could use *any* container for our needs (including faux-pax)
18:13:41  <auroraeosrose>yeah
18:14:25  <FearTheCowboy>coapp v1 is still going to be MSI, but v2 (which if the OS folks do the heavy lifting) would switch towards that (and be less than a year out)
18:14:50  <FearTheCowboy>and our community could focus on building OSS packages and stuff instead of the package manager :)
18:15:06  <vpovirk>I don't see the advantage of com over exe
18:15:26  <virmitio>we're going to need more bodies if we want to get the v2 feature set done in < 1yr
18:16:18  <FearTheCowboy>virmitio -> if the other folks do most of the work that kinda lifts it away from our shoulders a bit :)
18:16:52  <FearTheCowboy>vpovirk -> it doesn't look like a 'program' ... I dunno, I see "EXE" and I think "App" not "package" (not that .COM makes me think package either).
18:17:07  <FearTheCowboy>vpovirk -> the distiction is purely 'cosmetic'
18:17:18  <vpovirk>half of windows installers today are .exe
18:17:25  <vpovirk>the other half are .msi
18:17:33  <auroraeosrose>yes
18:18:01  <vpovirk>so to me it seems the better choice if you want something to be recognized as an installer
18:18:08  <FearTheCowboy>but nobody is distributing "openssl-dev-common-1.2.4.5-any-1231321231231.EXE" as a "package"
18:18:51  <FearTheCowboy>the only virtue of MSI ... is that a decade an a half of Windows tells us that it's an "installer"
18:18:54  <vpovirk>that's because packages don't exist
18:18:57  <FearTheCowboy>which, to me is kinda nice.
18:19:21  <FearTheCowboy>I'm willing to stay with .MSI as the outer package format just for that (and abandon Windows Installer for all the actual work)
18:19:23  <vpovirk>I thought msi was chosen because it's cross-arch
18:19:30  <FearTheCowboy>hmmm.
18:19:36  <FearTheCowboy>And vpovirk hits it on the head.
18:19:37  <FearTheCowboy>CRAP.
18:19:43  <vpovirk>even though I'm still not sure if that's true
18:19:49  <FearTheCowboy>I'll make sure I bring that up too.
18:20:17  <auroraeosrose>ah, yes, you are right
18:20:18  <FearTheCowboy>it is the only 'architecture-neutral' executable container format
18:20:42  <vpovirk>(i.e. can you make a .msi that both arm and x86 windows can run)
18:20:53  <FearTheCowboy>yes. that's true.
18:21:07  <FearTheCowboy>Pity, that as a format, it's kinda sucky. :)
18:21:55  <vpovirk>of course, a CLR stub might give you the same thing, sort of..
18:22:37  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:23:02  <FearTheCowboy>Except that the CLR stub won't work if the CLR isn't installed
18:23:23  <virmitio>which I don't think it is under server core
18:23:36  <FearTheCowboy>no, nor on 2008 out of th ebox.
18:24:23  <vpovirk>I guess a modern os will just give up before it calls the entry point then?
18:24:34  <vpovirk>if the runtime is missing
18:24:46  <FearTheCowboy>I dunno. haven't looked into it yet.
18:25:16  <virmitio>would it be reasonable to suggest a new format/extension that can be backported?
18:25:26  <vpovirk>I guess we can't really know what's cross-arch until we have an arm windows anyway
18:25:43  <FearTheCowboy>virmitio -> how do we frictionless bootstrap that?
18:26:16  <FearTheCowboy>ie, without having the "pkg manager" installed first, how do we grab the package and start the whole thing.
18:26:37  <virmitio>FearTheCowboy: I'm thinking along the lines of an "across the board" backport, which would include rolling it over Windows Update
18:27:32  <vpovirk>the wine project would love that
18:27:35  <FearTheCowboy>hmmm. that's really not likely.
18:27:59  <virmitio>if we skip assuming that's possible, or if we assume the individual isn't up to date, then I'm not entirely sure where to go with it
18:29:17  <virmitio>I've never tried, but would it be possible to build an exe with multiple entry points where the correct entry point for each arch is all that is used on a given machine?
18:29:44  <vpovirk>I don't think so
18:29:44  <FearTheCowboy>PE EXEs don't do that (they never invented fat binaries)... don't ask me why.
18:29:50  <vpovirk>is an x86 PE executable the only thing we can expect server core to run?
18:30:44  <FearTheCowboy>well, such a future version of core would have the pkg installer built in, and whatever it was, it would be able to recognize it's packages
18:31:08  <FearTheCowboy>so it could recognize an disguised MSI.
18:31:30  <vpovirk>I guess their format could "just happen" to be an ole storage ;)
18:31:35  <FearTheCowboy>my concern would be about existing platforms today (vista/2008/7/2008r2)
18:31:46  <FearTheCowboy>Yeah.
18:32:11  <FearTheCowboy>well, likely, they'd embed the whole contents of the package in the ole storage file as a CAB.
18:32:22  <FearTheCowboy>which is just clunky, but ... whaddaya do?
18:32:22  <auroraeosrose>dunno - this is a lot of "stuff for the future" and while it's nice to talk about it - it sounds like we cant' do more then conjecture until we get some idea of arm and the next generation of windows
18:32:49  <FearTheCowboy>Well, I have a meeting about it today... which is why I'm working thru the ideas.
18:33:00  <auroraeosrose>ah - well you can put that on the table
18:33:04  <FearTheCowboy>yeah.
18:33:08  <auroraeosrose>that a lot of decision making is going to depend on their choices
18:33:17  <auroraeosrose>we can only guess and try to adapt
19:07:32  * wwahammyjoined
19:09:15  * jgmdevquit (Quit: Thanks and take care everyone, lets make the world a better place to live :))
19:21:02  <auroraeosrose>ok
19:21:19  <auroraeosrose>if we EVER have a stupidity like this I will kill all packagers
19:21:29  <auroraeosrose>if you install libgtk2.0 on ubuntu - it installs mono
19:21:35  <auroraeosrose>the wtf there is so big I dont' know what to say
19:24:24  <FearTheCowboy>NIiiiice
19:29:01  <bob>according to the repo, mono is not a dependancy of libgtk2.0
19:29:06  <bob>so you gayed something else up
19:29:24  <bob>http://packages.ubuntu.com/precise/libgtk2.0-0
19:30:32  <bob>which matches my experiences this month.
19:35:09  <auroraeosrose>bob: or apt is possessed
19:36:41  <vpovirk>Breaks: gtk-sharp2 (<< 2.12.10-2ubuntu2), lxdm (<< 0.4.1-0ubuntu6), lxlauncher (<< 0.2.2-1ubuntu2), xfdesktop4 (<< 4.8.3-2ubuntu4)
19:36:58  <vpovirk>maybe you had old gtk-sharp2 and it upgraded for you?
19:37:10  <bob>that sounds plausable.
19:37:14  <auroraeosrose>possibly
19:37:24  <auroraeosrose>ubuntu puts everything and kitchen sink on by default
19:37:31  <auroraeosrose>I want a gui version with JUST simply gui
19:37:32  <vpovirk>silly package manager with a solver
20:01:45  * auroraeosrosequit (Read error: Connection reset by peer)
20:03:01  * auroraeosrosejoined
20:34:25  * piscisaureus_joined
20:37:49  * piscisaureus_quit (Read error: No route to host)
20:38:05  * piscisaureus_joined
21:11:53  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:29:37  * jgmdevjoined
21:40:49  * vpovirkquit (Read error: Connection reset by peer)
21:44:50  * piscisaureus_joined
22:15:01  * madewokherdjoined
22:36:48  * wwahammyquit (Ping timeout: 245 seconds)
22:39:05  * Jonny5quit (Quit: Leaving.)
22:50:48  * ender`quit (Quit: If it wasn't for C, we'd be writing programs in BASI, PASAL, and OBOL. -- A Programmer (@1Pr0grammer))
22:57:17  * Jonny5joined
22:57:18  * Jonny5quit (Changing host)
22:57:18  * Jonny5joined
23:26:35  * virmitioquit (Quit: Leaving.)
23:30:26  * auroraeosrosequit (Remote host closed the connection)
23:31:21  <FearTheCowboy>whoff.
23:31:28  <FearTheCowboy>just got done &hours* of meetings.
23:43:34  * Jonny5quit (Quit: Leaving.)