Re: Spam message when using CVS for webpages

[Ian Kelling]

Ineiev  writes:

> The problem is, we don't deploy the exactly same version for all
> Savannah hosts at once, we update them one by one, so you hardly
> would be able to tell which Git commit corresponds to software
> running on the particular host; this feature makes sure the users
> can download the right version.

I definitely admire the ingenuity to offer source code in more
places. However, I'm pretty confident Savannah webpages are a sufficient
place to satisfy the AGPL requirement of offering source, and adding
output like this to command line operations where the only expected
output is information related to the operation is undesirable for
various reasons and will very likely cause breakage for scripts and
tools which make calls to Savannah.

For the problem of different machines having different source, the link
for source at the bottom of savannah webpages could say something like:

"Savannah source repository is here: http://. Savannah is split onto
several machines, and the code running on some machines can lag behind
what is in our repository. Here is how to get the exact versions being
run:

To get the source code on the machine handling cvs requests, run

rsync -avz --cvs-exclude ga...@cvs.savannah.nongnu.org:/opt/src/savane .

To get the source code on the machine doing X, run ... (fill in more
here)"

Especially because this is likely to break other tools and annoy people,
I think it should be reverted until there is some consensus among
savannah hackers on the right solution.

Re: cgit syntax highlight request

[Ian Kelling]

Bob Proulx  writes:

> [[PGP Signed Part:Undecided]]
> Savannah Users,
>
> A user on IRC (daviid) has requested that cgit on Savannah be modified
> to perform syntax highlighting by default on the various source page
> display pages.
>
> I did some research into this topic of cgit syntax highlighting.  It
> seems there are two popular ways to enable syntax highlighting in
> cgit.  One uses the Python "Pygments" and one uses the standalone
> "highlight" utility.
>
> On IRC there were various comments about pygments and previous
> security vulnerabilities it has been through.  The other option using
> "highlight" I note is packaged for Debian and therefore if any
> security vulnerabilities were found that the security channel would
> normally provide a patch which would be quickly installed on our
> systems.  Therefore in my opinion using "highlight" would be the best
> option.

I agree. I actually got a patch into git for it's gitweb interface so
that it uses highlight as it's syntax highlighter. I think it used
pygments before, I can't remember for sure. Anyways, I did it because
highlight detected bash scripts and highlighted them, whereas the
previous highlighter did not.

>
> I tried it with both dark and light themes and it seems acceptable in
> either.  Which is important to me personally as I almost always use a
> dark theme when possible.
>
> Personally I rather prefer the non-colorized display.  Colors are one
> of those bike-shed items that everyone wants to be different.
> Therefore the common ground is often the no-color option.  I much
> prefer if people clone to their own sandbox and then they can use
> their own preferences for all bike-shed things like colors and fonts.
> But this is a shared resource and everyone is using it as a commons
> area.  I will bring the topic up for discussion.
>
> What is the opinion of the group at this time?  Should we enable
> syntax color highlight in cgit by default?

I'd prefer colorized output, but, first you should check the resource
use. When I made the git change, I found that highlight and pygments (i
think) had roughly equivalent performance, but I was surprised how much
cpu time they took up. So, I suggest check the page load time difference
for a few files: the extra time will be 100% cpu use of a forked
process.

> Should we leave color as
> it is now without?  Should we try it for a time period and see how it
> is received?  What would the users like to see here?
>
> Bob
>
> [[End of PGP Signed Part]]

Re: A question about hosting packages on Savannah

[Ian Kelling]

Ar Rakin  writes:

> Hi again.
>
> Aside of Discord Bots, I'm also building a terminal-based file manager that
> is only able to read files for now, but I'm implementing the things that
> are required for a file manager to have step by step.
>
> At this point, should I make a request for hosting at savannah.nongnu.org?
> I'm specially asking this since my project is not ready yet but will be
> ready soon, and if I'm allowed to do it now.
>
> Thanks in advance,
> Ar Rakin

I suggest waiting until it is usable.

Re: DNS issue affecting gnu.org (and subdomains)

[Ian Kelling]

Update: We think we've got things working now.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: Best way of converting CVS repo to git ?

[Ian Kelling]

Václav Haisman  writes:

> You might want to try to use http://www.catb.org/esr/cvs-fast-export/ to do
> that.
>
> út 3. 1. 2023 v 14:40 odesílatel Øystein Schønning-Johansen <
> oyste...@gmail.com> napsal:

I did a conversion of a cvs to git recently, i tried cvs-fast-export but
it kind of just thrashed the disk for 2 days. Then I used cvs2svn which
worked well. I think I used a debian buster chroot in order to quickly
use a packaged version. I can't find my notes at the moment.

Re: Authenticating git.savannah.gnu.org

[Ian Kelling]

Yuan Fu  writes:

> Hi,
>
> I’ve added my ssh key to savannah, and tried
>
> ssh caso...@git.savannah.gnu.org -i ~/.ssh/id_rsa
>
> However, it asks me for a password, I tried my savannah password and it 
> doesn’t work. What did I do wrong? Thanks.
>
> Yuan

try:

ssh -i ~/.ssh/id_rsa caso...@git.savannah.gnu.org
and if that doesn't work,
ssh -v -i ~/.ssh/id_rsa caso...@git.savannah.gnu.org

Re: Certificate Expiration Event September 2021

[Ian Kelling]

Bob Proulx  writes:

> On September 30, 2021, as planned the DST Root CA X3 cross-sign has expired
> for the Let's Encrypt trust chain.  That was a normal and planned event. 
> However coupled with a verification error in the code of libraries
> authenticating certificates it caused some clients that have not been updated
> to fixed versions to have problems validating certificates.
>
> If you are experiencing invalid certificate chain problems with Let's Encrypt
> certificates (not a Savannah problem) then please upgrade your client to the
> latest security patches for your system.  Please reference these resources as
> to upstream information and discussion about the issue.
>
> * https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
> * https://community.letsencrypt.org/t/production-chain-changes/150739/4
> * https://letsencrypt.org/docs/certificate-compatibility/
> * https://letsencrypt.org/certificates/
> * https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/
>
>
> ___
>   Message sent via Savannah
>   https://savannah.nongnu.org/

With a little googling, seems like this is the way to remove the expired
root cert on trisquel 8, suggested from
https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/

sudo sed -i"" 's/mozilla\/DST_Root_CA_X3.crt/!mozilla\/DST_Root_CA_X3.crt/' 
/etc/ca-certificates.conf
sudo dpkg-reconfigure -fnoninteractive ca-certificates
sudo update-ca-certificates

Re: Testing if this message reaches the savannah-users

[Ian Kelling]

Vaidas BoQsc  writes:

> The previous message seems to not be posted in the savannah-users archive I
> wonder why.

I got it.

Please tell me as much of the following and I will look into it: When
exactly did you send it, what was the subject, what was the Message-id
header, what address was it from.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: Email notifications from bug tracker

[Ian Kelling]

Markus Mützel  writes:

> Hello,
>
> since about Friday evening, I no longer receive any email notifications from 
> the savannah bug tracker of GNU Octave:
> https://savannah.gnu.org/bugs/?group=octave
>
> The last notification email I received was from Friday, 2020 Oct 2 at 21:45 
> CEDT.
>
> I looks like other group members don't receive any notifications either.
>
> The list archive also doesn't receive updates:
> https://lists.gnu.org/archive/html/octave-bug-tracker/2020-10/index.html
>
> Could you please check if there is something wrong with the email 
> notifications?
>

It looks like frontend1.savannah.gnu.org is not sending new bug messages
to eggs, probably something going wrong there. I see one post sent from
a normal person today that seemed to be processed find by eggs and
mailman. It was discarded due to the rules of the list. Adding Bob, as
he is probably the best person to look into the savannah side.

Oct 07 15:04:20 2020 (2314) Octave-bug-tracker post from j...@jweaton.org held, 
message-id=: Post by 
non-member to a members-only list
Oct 07 15:04:34 2020 (30017) octave-bug-tracker: Discarded posting:
From: j...@jweaton.org
Subject: test message
Reason: Non-members are not allowed to post messages to this list.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: Eligibility of CC-BY-SA for documentation within a software project

[Ian Kelling]

Ineiev  writes:

> On Fri, Feb 28, 2020 at 05:55:00AM +, Ineiev wrote:
>> >
> ... 
>> > As far as I can recall, we are not allowed to accept gpl for manuals,
>> > although that seems draconian
> ...
>
> The GFDL is the license for GNU manuals; if some documentation
> is FDL-incompatible, GNU packages won't be able to use it, and
> it's expected that the GNU project should be able to copy
> from packages hosted on Savannah.

Right, that makes sense why its not accepted. I didn't think about it
much before I sent my email.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: Eligibility of CC-BY-SA for documentation within a software project

[Ian Kelling]

Karl Berry  writes:

> Hi Anton,
>
> CC-BY-SA is considered eligible for artworks, but it is not clear if
> it is acceptable for the software documentation.
>
> Generally speaking, CC-BY-SA is not acceptable for documentation (or
> code) on Savannah, because it is not compatible with the FDL (or GPL).
> That's not an issue for artwork, but is for manuals.
>
> Is there any chance of relicensing the manual to the FDL (or compatible)?
>
> If not, we could ask rms if he'd be willing to make an exception.
> In which case, he will surely want to know what the project actually is :),
> so please advise.
>
> Thanks for considering Savannah. --best, karl.

cc-by-sa became gplv3 compatible. Still not gfdl compatible.
https://creativecommons.org/2015/10/08/cc-by-sa-4-0-now-one-way-compatible-with-gplv3/
In that light, I hope it would be allowed.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: [Savannah-users] Fwd: qemu-devel mailing list dropping certain emails consistently

[Ian Kelling]

Bin Meng  writes:

> +Peter
>
> Hi Ian,
>
> On Tue, Aug 27, 2019 at 3:22 AM Ian Kelling  wrote:
>>
>>
>> Ian Kelling  writes:
>>
>> > Ian Kelling  writes:
>> >
>> >> Bin Meng  writes:
>> >>
>> >>> Hi Ian,
>> >>>
>> >>> On Mon, Aug 26, 2019 at 8:13 AM Ian Kelling  wrote:
>> >>>>
>> >>>> Hi Bin,
>> >>>>
>> >>>> Bob is right, but I do check this list and I will figure out what went
>> >>>> wrong tomorrow. It might help if you try sending the patch email to my
>> >>>> email directly, i...@fsf.org.
>> >>>>
>> >>>
>> >>> Thank you very much for your help.
>> >>>
>> >>> I just resent the v3 patch [20/28] and [26/28] directly to you and the
>> >>> QEMU mailing lists, using the following git command:
>> >>>
>> >>> $ git send-email --to "Ian Kelling " --to
>> >>> "qemu-de...@nongnu.org" --to "qemu-ri...@nongnu.org" --bcc
>> >>> "my_another_email_address" 
>> >>>
>> >>> I checked "my_another_email_address" and confirmed I received these 2
>> >>> patches, but from the QEMU mailing list archive, looks they do not get
>> >>> any luck arriving at the mailing lists again.
>> >>>
>> >>> Please take a look.
>> >>>
>> >>> Regards,
>> >>> Bin
>> >>
>> >> I figured out the issue, it got misclassified as spam. I've got to run,
>
> Great! Looks the mystery of the QEMU mailing lists are finally
> cleared. Adding Peter so that he is aware.
>
> Bad to know these patches were tagged as spam.
>
>> >> but I'll make a fix in about 2 hours and will message then or so. Bob,
>> >> do you think we should just make lists.gnu.org have an overall lower
>> >> spam bar?
>> >
>> > In this case, it seems spamassassin misclassified the language of the
>> > emails because of the code in them. I've seen this issue before. We have
>
> Yes, Peter mentioned to me he saw random patch email was dropped with
> QEMU lists before I requesting help on this mailing list the other
> day.
>
>> > a rule for bad language + freemail, I've lowered it a point.  Sometime
>> > in the next month or so I'm going to dig into spamassassin and hopefully
>> > make a better fix. I'm going to push through the missing emails now.
>>
>> I pushed them through, sorry, I mistakenly sent one that was no version,
>> the other one v2, although the body says nothing was changed.
>
> Thanks, although the same patch is now at v5 and still 2 patches were missing:
> https://patchew.org/QEMU/1566537069-22741-1-git-send-email-bmeng...@gmail.com/
>
> Thank you very much for figuring out the issue and all the help
> provided. Just hoping my future patches will not be marked as spams :)
>
> Regards,
> Bin

Bin, I can't tell which 2 are missing from the link. please resnd
them. If you have trouble again, please email sysad...@gnu.org, and if
you want a faster response than a day or so, please ping me on freenode,
in #fsfsys, iank.

Re: [Savannah-users] Fwd: qemu-devel mailing list dropping certain emails consistently

[Ian Kelling]

Bin Meng  writes:

> Hi Ian,
>
> On Mon, Aug 26, 2019 at 8:13 AM Ian Kelling  wrote:
>>
>> Hi Bin,
>>
>> Bob is right, but I do check this list and I will figure out what went
>> wrong tomorrow. It might help if you try sending the patch email to my
>> email directly, i...@fsf.org.
>>
>
> Thank you very much for your help.
>
> I just resent the v3 patch [20/28] and [26/28] directly to you and the
> QEMU mailing lists, using the following git command:
>
> $ git send-email --to "Ian Kelling " --to
> "qemu-de...@nongnu.org" --to "qemu-ri...@nongnu.org" --bcc
> "my_another_email_address" 
>
> I checked "my_another_email_address" and confirmed I received these 2
> patches, but from the QEMU mailing list archive, looks they do not get
> any luck arriving at the mailing lists again.
>
> Please take a look.
>
> Regards,
> Bin

I figured out the issue, it got misclassified as spam. I've got to run,
but I'll make a fix in about 2 hours and will message then or so. Bob,
do you think we should just make lists.gnu.org have an overall lower
spam bar?

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: [Savannah-users] Fwd: qemu-devel mailing list dropping certain emails consistently

[Ian Kelling]

Hi Bin,

Bob is right, but I do check this list and I will figure out what went
wrong tomorrow. It might help if you try sending the patch email to my
email directly, i...@fsf.org.


Bob Proulx  writes:

> Hello Bin,
>
>> This is really annoying. Please investigate what's wrong with
>> the mailing list service. Thanks!
>
> You are emailing the Savannah Users mailing list.  I don't know if
> anyone here is going to be able to help you.  Savannah and Savannah
> Users don't have much if anything to do with the mailing lists.
>
> Please send your request for help to mail...@gnu.org (since this is a
> Mailman thing) or to sysad...@gnu.org (since it is likely a rejection
> on the incoming mail relay system eggs) and ask there.  Those are the
> places where the FSF admins who need to see this hang out.
>
> Switching roles to the Listhelper anti-spam role I looked and I do not
> see any discarding happening due to the anti-spam that I have control
> over.  I don't see those missing messages appearing at all.  Therefore
> I suspect they are getting rejected by a content filter on eggs and I
> have no access nor any visibility there.
>
> Bob
>
>
> Bin Meng wrote:
>> Hi,
>> 
>> It was observed that the qemu-devel mailing list consistently drops
>> certain emails for unknown reasons.
>> 
>> This was seen for below patch series emails sent to on qemu-devel and
>> qemu-riscv mailing lists, both of which are hosted on
>> savannah.nongnu.org.
>> 
>> [Qemu-devel] [PATCH v2 00/28] riscv: sifive_u: Improve the emulation fid
>> https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg00987.html
>> 
>> [Qemu-devel] [PATCH v3 00/28] riscv: sifive_u: Improve the emulation fid
>> https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg01869.html
>> 
>> You can see from above archive that patch email [20/28] and [26/28] are 
>> missing.
>> 
>> These patch emails were sent using 'git send-email' via gmail's smtp
>> service. To troubleshoot the problem, I resent these 2 emails to
>> qemu-devel/qemu-riscv mailing list twice, but mailing list did not
>> receive them. To verify whether it is related to gmail itself, I
>> included a 'bcc' to my another private email address at the same time
>> when I sent to these 2 mailing lists, and my another private email
>> address did receive these 2 patch emails.
>> 
>> Note: patchew also reported that only 26 patches were received. See below:
>> 
>> v2: 
>> https://patchew.org/QEMU/1565163924-18621-1-git-send-email-bmeng...@gmail.com/
>> v3: 
>> https://patchew.org/QEMU/1565510821-3927-1-git-send-email-bmeng...@gmail.com/
>> 
>> So the problem seems to be with the qemu-devel/qemu-riscv mailing
>> lists. This is really annoying. Please investigate what's wrong with
>> the mailing list service. Thanks!
>> 
>> Regards,
>> Bin
>> 

Re: [Savannah-users] Regarding changing the project URL on Savannah

[Ian Kelling]

I agree. Also, since this hasn't been answered, I'd try asking on the
savannah-hackers-public list.

Marcus Müller  writes:

> Hi Nirmal,
>
> I'm in no way associated with the folks actually running the savannah
> web interface, but:
>
> be careful what you wish for! Changing the URL to a project will break
> links all over the place, so maybe you should dare to ask for a URL
> forwarding, at the very least. This is of no concern if you know your
> project has very few users, but if you don't: don't leave
> packagers/maintainers out in the rain by changing the URL of your
> project without any way to find out what the new one is.
>
> Best regards,
> Marcus
>
>
> On Sun, 2018-09-30 at 19:48 +, Nirmal Almara wrote:
>> Hi,
>> 
>> This is Nirmal, I have a project in savannah called LibreRead.
>> https://savannah.nongnu.org/projects/libreread/
>> joyread - Summary [Savannah]<
>> https://savannah.nongnu.org/projects/libreread/>
>> Savannah is a central point for development, distribution and
>> maintenance of free software, both GNU and non-GNU.
>> savannah.nongnu.org
>> 
>> I'm changing the brand name to Joyread. I have already changed the
>> project name in Savannah but the URL is still "libreread". Is there
>> anyway we can change the URL of this project to 
>> https://savannah.nongnu.org/projects/joyread
>> ; ?
>> 
>> Thanks,
>> Nirmal