Re: [PATCH setup 0/3] Setup replacement for incver_ifdep
On 12/10/2015 18:38, Achim Gratz wrote: Jon Turney writes: On 22/09/2015 16:52, Jon Turney wrote: [...] As for your patches, I think that the first two (getting rid of the regex engine and the incomplete implementation of autodep: lines) are non-controversial and should be applied. Ok, thanks. I still don't think the triggers should be implemented or at least not in the way you've been proposing. Can you explain the reason why? I've meanwhile looked a bit deeper on what it would take to update the info dir using perpetual scripts and it seems it is about the same effort as the incremental autorebase. The easiest path would be to keep the script the same as it is now and just check if a package with info files got installed or removed. I think that's more or less what I implemented. But it would be possible to just add / remove the corresponding entries with a bit more bookkeeping. I'll try something of that, but not immediately. I guess that list of matching files added/removed could be written into or associated with the trigger file, but the benefit starts to look a bit marginal, (especially as this is not intended as a general solution, but only for use with _update-info-dir, and other future package-to-package triggers are written directly in the packages themselves)
Obsolete dependency report, 2015-Oct-15
With the ABI-breaking updates to Boost and ICU, there are a number of packages which now need to be rebuilt: gnuplot Dr. Volker Zell lyx Marco Atzeri mkvtoolnix David Stacey nmh David Levine pristine-tar[3] Jari Aalto pstoedit Dr. Volker Zell RMarco Atzeri rdtool[1]Jari Aalto rpm Pavel Fedin sng[2] Andrew Schulman sqlite3 Jan Nijtmans tesseract-ocrMarco Atzeri znc Alexey Sokolov [1] subject to removal from the distribution [2] https://cygwin.com/ml/cygwin-apps/2015-02/msg00152.html [3] already rebuilt for x86_64, but not i686 The master list is kept at: https://docs.google.com/document/d/1eiQ0Mcp588cVVt5LaYXQG5i_HznVF14k50j_pneGT68/edit?usp=sharing This page is set for moderated changes, so feel free to strikethrough your package from the list once its uploaded. TIA, Yaakov
Re: Reproducible Builds
Achim Gratz writes: > Has anybody tried to make cygport builds reproducible? Thanks for all responses so far. I take it to mean that indeed nobody has tried to do it before and that I can't look at something that I can start with. Something else for the future, then. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
setup.exe not logging on Windows 10 with MS accounts
In another thread [1] I discovered that setup.exe hasn’t logged anything to /var/log/setup.log since November 2014, despite running it occasionally during that time. I have ruled out permission problems, since I can write to that file as both a normal user and from an admin shell. The latter should mimic the permissions setup.exe has while running under UAC, which is enabled on this box. I later removed the setup.log files, and they weren’t re-created. I thought the problem was that setup.exe doesn’t enable the logger when running elevated permissions (main.cc, line 290), but Achim Gratz dug deeper and says it should relaunch itself again and then enable the logger. Achim Gratz noted that my default permissions may be weird because I am running with a Microsoft Account rather than a local one. I have no particular need to run a MS account, I just took the default it pushed me into, since I upgraded this VM to Windows 10 to test Windows 10. Might as well use it with its defaults as much as possible, yes? No point testing a new OS if I’m just going to turn off everything that’s new about it. [1]: https://cygwin.com/ml/cygwin/2015-10/msg00179.html
Re: [PATCH setup 0/3] Setup replacement for incver_ifdep
Jon Turney writes: >> I still don't think the triggers should be implemented or at least not >> in the way you've been proposing. > > Can you explain the reason why? Triggers need to be coordinated among packages and we currently don't have an infrastructure for that. And implementing just a single trigger for info files is special-casing this thing too much. > I think that's more or less what I implemented. I'm talking about doing it with a perpetual postinstall script. >> But it would be possible to just add / >> remove the corresponding entries with a bit more bookkeeping. I'll try >> something of that, but not immediately. > > I guess that list of matching files added/removed could be written > into or associated with the trigger file, but the benefit starts to > look a bit marginal, (especially as this is not intended as a general > solution, but only for use with _update-info-dir, and other future > package-to-package triggers are written directly in the packages > themselves) Again, I don't see why updating the info dir should be so special, it can be done in postinstall without getting special-cased in setup: Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
