Re: [ITP] git-crypt 0.6.0
On 2019-08-09 19:48, Nick Nauwelaerts wrote: > On Friday, August 9, 2019 08:15, Brian Inglis wrote: >> On 2019-08-08 22:17, Nick Nauwelaerts wrote: >>> git-crypt is a git plugin that transparently handles encryption/decryption >>> of files in combination with git. i've used it on and off again when i need >>> to place sensitive info on a location that could be public (or as most ppl >>> seem to use it: to save dotfiles on github without all your private stuff >>> being world readable). i've been using it sporadicly in cygwin for 2 months >>> as well without any issues. >>> >>> as such i made a cygport of it, but i'm not quite clear on how the process >>> works to submit it. >> >> See also: >> >> https://cygwin.com/packaging-contributors-guide.html >> https://cygwin.com/packaging-hint-files.html >> https://cygwin.com/packaging-package-files.html > > i actually did go through all those to try and get everything right on the > first go, seems i missed some things :) > >> https://cygwin.com/package-server.html > > since this seemed to be such a simple package i must admit i did not set up > a mirror, i did however follow > https://cygwin.com/packaging-contributors-guide.html (Installing your > package for testing), extracting everything in my root dir as explained > there. i assumed this would suffice since the package only contains 1 binary > & 1 man page and no scripts or anything special that needs to be run. > >> https://cygwin.com/package-upload.html > > i figured if i made the cygport file and patches available you would import > them in a build system like suse's openbuild to verify that no shortcuts were > taken or my system was otherwise not comparable to normal install. come to > think of it, kinda like what is proposed here: > https://cygwin.com/ml/cygwin-apps/2019-08/msg00012.html :) > >> but ignore anything that does not jive with cygport doing most of the grunt >> work >> for you: >> >> $ cygport package.cygport download all test upload announce > > since i didn't bother with requesting access upload of course fails, also > making announce irrelevant. i'll will send an email with a key in the > requested mail format asap. > >> >> but you might want to run the latter two separately after manually installing >> and using the packages under Cygwin on your system. >> >>> cygport file & patches are here: https://github.com/inphobia/git- >> crypt.cygport >>> >>> cygport file was written by me, windows patches came from the issue >> tracker, >>> a link to the original patch is included as a comment in each patch file. >>> >>> it completes all cygport steps (compile, package, etc, ...) just fine and >>> the >>> resulting package seems to be compliant. >>> >>> major distro references as requested for new packages: >>> https://software.opensuse.org/package/git-crypt >>> https://packages.debian.org/sid/git-crypt >> >> You can also check package availability easily on https://pkgs.org/: >> >> $ cygstart https://pkgs.org/download/git-crypt >> >> shows Alt Linux, Arch Linux, Debian, Fedora, FreeBSD, OpenSuSE, Ubuntu. >> >>> license: gpl v3 >>> >>> tested on windows 10 x64 - 1903, cygwin 3.0.7 >> >> You also have to build on x86 and provide public links to the >> package.cygport, >> source package-ver-1-src.tar.xz, x86 and x86_64 binary package-ver-1.hint, >> package-ver-1.tar.xz, x86 and x86_64 debuginfo package-debuginfo-ver-1.hint >> and >> package-debuginfo-ver-1.tar.xz files, from the build package-ver-1.arch/dist >> subdirectories. > > uploaded them all here (x64 only): > https://github.com/inphobia/git-crypt.cygport/releases/tag/0.6.0-1.beta > > because, for some reason the 32bit versions fails to build. > > the first try i didn't have the required packages: > *** ERROR: Compiling this package requires i686-pc-cygwin binutils and gcc > > so i installed all cygwin32* packages. seems i also has some mingw64-i686 > packages left over which i uninstalled so the wouldn't get in the way. > and then my build broke with a missing ssl header for some reason: > > crypto-openssl-10.cpp:31:33: fatal error: openssl/opensslconf.h: No such file > or directory > #include > > am i missing something obvious here like the i686 toolchain having different > include paths or compiler arguments? or does openssl actually have different > headers depending on arch, which is what quite a lot of google answers seem > to point to. Download setup-x86 and set up a Cygwin 32 install parallel to your Cygwin 64 install, install base, cygport, and dependencies, open a Cygwin 32 mintty window, running Cygwin 32 bash, cd to your git-crypt.cygport dir, and rerun your cygport download all test. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
Re: [ITP] italic-man
On 2019-08-10 03:07, Thomas Wolff wrote: > Am 09.08.2019 um 22:51 schrieb Brian Inglis: >> On 2019-08-09 13:31, Thomas Wolff wrote: >>> Am 09.08.2019 um 20:56 schrieb Achim Gratz: Jon Turney writes: > This gets a GTG from me. > I believe that according to our stated procedures additional approvals > are required, because this package is unique to cygwin. I'm not sure I remember correctly from when the discussion went on the first time, but wasn't there some mumbling about this partly going into groff? If that's still the case, remind me what this would entail and I'll look into it. >>> There are multiple ways of activating the feature (also described in the man >>> page). >>> The previous strategy placed a shell script wrapper "groff" aside groff, so >>> the >>> groff script and groff.exe would coexist in /bin. This was tricky to >>> install and >>> particularly it reportedly did not survive a package update of groff. >>> The new approach does not use this wrapper anymore. Instead it redirects >>> nroff >>> to the package-supplied iroff script by configuration in /etc/man_db.conf. How are updates to man-db, /etc/man_db.conf etc. handled? Is a permanent postinstall script provided to maintain the conf on man-db updates? >> There's also use of the undocumented LESS_TERMCAP_... with GROFF_NO_SGR env >> vars >> (see attached - must be sourced from profile or rc) to remap bold, underline, >> etc. into italic and/or colour, or whatever else you want to change, in all >> less >> output. > So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls > should have the same effect? Cannot reproduce. And what does GROFF_NO_SGR do? Those settings affect all *less* output, not just *man*. Some people can't stand any colours (white on black was good enough for my grandfather...) the same as I couldn't wait for decent fonts, graphics, and colour support on something other than plotters, like displays and printers, and then for files. Options are good, to allow users to choose where and what is affected, and how. Sorry, been messing around with colours, fonts, graphics, and SGR sequences so much, that I can't remember what led to what. You need the reset sequences also. Set GROFF_NO_SGR=1 to pass old bold/italic overstrikes thru for less to colourize - looks like if GROFF_NO_SGR just exists it works: $ LESS_TERMCAP_md=$(tput bold)$(tput setaf 4) \ LESS_TERMCAP_me=$(tput sgr0) \ LESS_TERMCAP_us=$(tput sitm)$(tput setaf 4) \ LESS_TERMCAP_ue=$(tput ritm)$(tput sgr0) \ GROFF_NO_SGR= man man bold is also bright blue, underline is shown as italic in blue: the attached now sets these up in the env. Other uses of SGR sequences are in e.g.: $ GREP_COLORS='mt=0;33;44;1;7:ln=34' grep -bnHi color ~/.bash* which on mt matches resets SGR, then sets fg colour yellow, background blue, enables bold, then reverses those colours, to display bold blue on bright yellow, line numbers in green, defaulting file names to magenta, and byte counts in blue; also e.g.: $ \ GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'\ gcc -g -Og -Wall -Wextra -c mintty_config.c as I run black fg text in white bg windows, and bright yellow fg warnings are invisible; just like blue fg messages in black bg windows, most combos of magenta and red, and many of cyan and green: those similar hues should be unmappable pairs in any colour palette! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. #|/bin/sh # .LESS_TERMCAP - set termcap properties for man and other less paging # What things in a manpage use which capabilities? # man and less use: # bold for headings, command synopses, and code font # underline for proper names (for example, “termcap” and “terminfo” in the # termcap manpage), variable names (“name”, “bp”, “id”, etc.), and type names # in some manpages (such as dispatch_queue_create(3)) # standout for the prompt at the bottom # It doesn’t seem like anything uses blinking. # termcap terminfo #LESS_TERMCAP_ks=$(tput smkx) # kssmkxmake the keypad send commands #LESS_TERMCAP_ke=$(tput rmkx) # kermkxmake the keypad send digits #LESS_TERMCAP_vb=$(tput flash) # vbflash emit visual bell #LESS_TERMCAP_mb=$(tput blink) # mbblink start blink #LESS_TERMCAP_md=$(tput bold) # mdboldstart bold LESS_TERMCAP_md=$(tput bold)$(tput setaf 4) # mdboldset mode bold 4 set colour blue #LESS_TERMCAP_mh=$(tput dim)# mhdim mode half-bright #LESS_TERMCAP_mr=$(tput rev)# mrrev mode reverse video LESS_TERMCAP_me=$(tput sgr0)# mesgr0reset attributes #LESS_TERMCAP_so=$(tput smso) # sosmsostart standout (reverse video) #LESS_TERMCAP_se=$(tput rmso) # sermsostop standout
Re: [ITP] italic-man
Am 10.08.2019 um 11:07 schrieb Thomas Wolff: Am 09.08.2019 um 22:51 schrieb Brian Inglis: On 2019-08-09 13:31, Thomas Wolff wrote: Am 09.08.2019 um 20:56 schrieb Achim Gratz: Jon Turney writes: This gets a GTG from me. I believe that according to our stated procedures additional approvals are required, because this package is unique to cygwin. I'm not sure I remember correctly from when the discussion went on the first time, but wasn't there some mumbling about this partly going into groff? If that's still the case, remind me what this would entail and I'll look into it. There are multiple ways of activating the feature (also described in the man page). The previous strategy placed a shell script wrapper "groff" aside groff, so the groff script and groff.exe would coexist in /bin. This was tricky to install and particularly it reportedly did not survive a package update of groff. The new approach does not use this wrapper anymore. Instead it redirects nroff to the package-supplied iroff script by configuration in /etc/man_db.conf. There's also use of the undocumented LESS_TERMCAP_... with GROFF_NO_SGR env vars (see attached - must be sourced from profile or rc) to remap bold, underline, etc. into italic and/or colour, or whatever else you want to change, in all less output. So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls should have the same effect? Cannot reproduce. And what does GROFF_NO_SGR do? Ah, this works: GROFF_NO_SGR= LESS_TERMCAP_us="^[[3m" LESS_TERMCAP_ue="^[[23m" man ls no matter what the value of GROFF_NO_SGR is. Which tool in the `man` chain interprets the latter? Value-added of my package: * automatic injection into the `man` pipe * terminal-dependent enabling, after checking the terminal type
Re: Did I miss something? cscope v15.9.1 has been released ...
On Sat, 10 Aug 2019 10:36:36, =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= wrote: > Am 10.08.2019 um 10:01 schrieb Houder: > > > Remarkably https://sourceforge.net/projects/cscope/ (news) > > reports v15.8b as the last release ... > > > > ... though v15.9 is mentioned at a different tab (git). > > > > But really, what changed? (why NO annoucement?) > > That one's on me. I'm the maintainer of upstream cscope. There were > some unfortunate events around the release of 15.9 which apparently > distracted me enough to make me forget to actually post a NEWS item. > > I'll do that now (a bit over a year leater)... :-) Thank you! Awaiting your release message for 15.9 (on SF). Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] italic-man
Am 09.08.2019 um 22:51 schrieb Brian Inglis: On 2019-08-09 13:31, Thomas Wolff wrote: Am 09.08.2019 um 20:56 schrieb Achim Gratz: Jon Turney writes: This gets a GTG from me. I believe that according to our stated procedures additional approvals are required, because this package is unique to cygwin. I'm not sure I remember correctly from when the discussion went on the first time, but wasn't there some mumbling about this partly going into groff? If that's still the case, remind me what this would entail and I'll look into it. There are multiple ways of activating the feature (also described in the man page). The previous strategy placed a shell script wrapper "groff" aside groff, so the groff script and groff.exe would coexist in /bin. This was tricky to install and particularly it reportedly did not survive a package update of groff. The new approach does not use this wrapper anymore. Instead it redirects nroff to the package-supplied iroff script by configuration in /etc/man_db.conf. There's also use of the undocumented LESS_TERMCAP_... with GROFF_NO_SGR env vars (see attached - must be sourced from profile or rc) to remap bold, underline, etc. into italic and/or colour, or whatever else you want to change, in all less output. So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls should have the same effect? Cannot reproduce. And what does GROFF_NO_SGR do?
Re: Did I miss something? cscope v15.9.1 has been released ...
Am 10.08.2019 um 10:01 schrieb Houder: > Remarkably https://sourceforge.net/projects/cscope/ (news) > reports v15.8b as the last release ... > > ... though v15.9 is mentioned at a different tab (git). > > But really, what changed? (why NO annoucement?) That one's on me. I'm the maintainer of upstream cscope. There were some unfortunate events around the release of 15.9 which apparently distracted me enough to make me forget to actually post a NEWS item. I'll do that now (a bit over a year leater)... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Did I miss something? cscope v15.9.1 has been released ...
L.S., The mirror show v15.9.1 of cscope ... This version has been released by Jari Aalto ... as far as I can tell. Did I miss the announcement? What changed? Remarkably https://sourceforge.net/projects/cscope/ (news) reports v15.8b as the last release ... ... though v15.9 is mentioned at a different tab (git). But really, what changed? (why NO annoucement?) Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
