From: Keith M. <kei...@us...> - 2013-09-09 22:11:58
|
On 09/09/13 22:45, Earnie Boyd wrote: >> Earnie, I did an "hg pull -u" on mingw-dist, this morning, followed by a >> "make". My previously up to date sandbox registered a bunch of remade >> catalogue files. Did you, perhaps, push the source modifications before >> you remade the targets, and neglect to push the updated issue.log files? >> Were the updated targets published to FRS? > > The git server would not let me push dirty, the client would get an > error. I have been using the ``make published'' process you put into > place since the first day it was available. I always make published > before doing a commit and push. I usually check that both issue.log > are included in the commit. Looking at the history of the commit I > see that they were indeed included. Could the effect you see be > related to file timestamps? I doubt it; the remakes for publication are driven by SHA1 hash changes in the issue.log files. I've no idea why: my pulls seem to be getting everything except your issue.log updates, which they definitely are not getting. FWIW, I just pulled your last changeset, remade, published, and pushed. Can you now pull a consistent issue.log state? -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2013-09-09 22:26:39
|
On 09/09/13 23:11, Keith Marshall wrote: > FWIW, I just pulled your last changeset, remade, published, and pushed. > Can you now pull a consistent issue.log state? And now, in a clean sandbox, for me mingw-get no longer chokes on a mingw32-base.bin + mingw32-gcc-c++.bin install. -- Regards, Keith. |
From: Sebastian S. <ssc...@gm...> - 2013-09-10 09:29:19
|
On 10.09.2013 00:26, Keith Marshall wrote: > And now, in a clean sandbox, for me mingw-get no longer chokes on a > mingw32-base.bin + mingw32-gcc-c++.bin install. Works again for me, too. Thanks! -- Sebastian Schuberth |
From: Earnie B. <ea...@us...> - 2013-09-09 22:35:10
Attachments:
diff.txt
|
On Mon, Sep 9, 2013 at 6:11 PM, Keith Marshall wrote: > On 09/09/13 22:45, Earnie Boyd wrote: >>> Earnie, I did an "hg pull -u" on mingw-dist, this morning, followed by a >>> "make". My previously up to date sandbox registered a bunch of remade >>> catalogue files. Did you, perhaps, push the source modifications before >>> you remade the targets, and neglect to push the updated issue.log files? >>> Were the updated targets published to FRS? >> >> The git server would not let me push dirty, the client would get an >> error. I have been using the ``make published'' process you put into >> place since the first day it was available. I always make published >> before doing a commit and push. I usually check that both issue.log >> are included in the commit. Looking at the history of the commit I >> see that they were indeed included. Could the effect you see be >> related to file timestamps? > > I doubt it; the remakes for publication are driven by SHA1 hash changes > in the issue.log files. I've no idea why: my pulls seem to be getting > everything except your issue.log updates, which they definitely are not > getting. > > FWIW, I just pulled your last changeset, remade, published, and pushed. > Can you now pull a consistent issue.log state? Maybe a TZ difference? I pulled and did make. The issue.log files changed; difference is attached. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2013-09-10 07:04:44
|
On 09/09/13 23:35, Earnie Boyd wrote: >>> I doubt it; the remakes for publication are driven by SHA1 hash changes >>> in the issue.log files. I've no idea why: my pulls seem to be getting >>> everything except your issue.log updates, which they definitely are not >>> getting. >> >> FWIW, I just pulled your last changeset, remade, published, and pushed. >> Can you now pull a consistent issue.log state? > > Maybe a TZ difference? Seems unlikely. > I pulled and did make. The issue.log files changed; difference is > attached. That's strange. The diff from *my* push tells a different story: https://sourceforge.net/p/mingw/mingw-dist/ci/9f2c59901932d14fcc3b1f3475d5b11fdf99f482/ -- Regards, Keith. |
From: Joaquin M. <jme...@ve...> - 2013-09-11 23:53:26
|
I'm guessing that mingw-get would be agnostic regarding any particular packaging system. I was going to look into putting together an installer package and perhaps as I get more familiar with Chocolately and see what's involved in doing something like: chocolatey mget packageName cmget packageName cinst packageName -source mget clist -source mget On 9/8/13 11:48 AM, Pau Garcia i Quiles wrote: > > > On Sunday, September 8, 2013, Earnie Boyd > <ea...@us... <mailto:ea...@us...>> > wrote: > > > I'm thinking though that some of these > > issues are stemming from mingw-get itself > > > Does it make se se to use mingw-get? Maybe back in its day it did but > these days there are nuget, chocolatey and even apt-get for windows, > which solve all those technical problems > > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: Keith M. <kei...@us...> - 2013-09-12 00:06:52
|
On 12/09/13 00:53, Joaquin Menchaca wrote: > I'm guessing that mingw-get would be agnostic regarding any particular > packaging system. Huh? mingw-get expects tarballs, with its own very specific XML document model for describing them. Any other packaging standard is off-limits here. -- Regards, Keith. |