Who's using Debian
Imperial Leisure, Creative Agency in London & Singapore [link: https://www.imperialleisure.com] We use Debian for our hosting our web development projects and with our Docker projects. As well as using Debian on production servers we also use it on our staging servers. We prefer it for its ease of use and security. Thank you! Best, Yunus
Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster
Hi all, On Mon, 8 Jun 2020 00:35:26 +0200 Cyril Brulebois wrote: > (Looping in wml package maintainer + original author) > Some notes: 1. I am not the original author of wml, just the current upstream maintainer (though I believe that I have invested quite a lot of work in it). 2. The newest release of wml is 2.28.0 (see https://github.com/thewml/website-meta-language/releases ) while Debian sid is stuck at 2.12.x (see https://packages.debian.org/sid/wml ). I'd rather not support such an old release, so if the new version still exhibits some regressions, please send a failing testcase to https://github.com/thewml/website-meta-language/tree/master/src/wml_test and I'll try to fix it. For a joke about it, see: https://www.shlomifish.org/humour/fortunes/tinic.html#hamakor-discs-mozilla-1.1-1 3. I recommend the Debian site to gradually transition away from using wml, because while wml is fairly powerful and flexible, it is slow, quirky and hard to learn. It is a hindrance that the debian site takes 3 hours to build on a modern computer: https://xkcd.com/303/ Converting some of my sites away from wml has shortened their build times considerably. Regards, Shlomi > Hi! > > Laura Arjona Reina (2020-06-07): > > Thanks Cyril for your work here. > > > > We're trying to fix all the issues so the migration of www-master to > > buster can be done as soon as possible. > > You're welcome, helping towards that goal was my original intent. > > > I'll comment on the issues you found: > > > > 1. Changes related to canonicalization(?) of the URL > > > > The files affected are: > > > > 1.1.- */News/news.*.rdf (all languages) > > > > All those files are built using /english/News/news.rdf.in which includes > > this line: > > > > > > > > it seems that the variable $(HOME) is interpreted differently by the > > make or wml commands in buster. > > > > I have played with the "-D HOME~." line in /english/.wmlrc but it does > > not solve the issue. > > > > The file is built (in english and all the other languages except > > Chinese) by lines 36-37 of the /english/News/Makefile: > > > > $(WML) $(shell egrep '^-D (CUR_|CHAR)' ../.wmlrc) \ > > $(ENGLISHDIR)/News/news.rdf.in > > > > If I change that to > > > > $(WML) $(shell egrep '^-D (CUR_|CHAR)' ../.wmlrc) news.rdf.in > > > > then the English file is built with correct URL to the CSS, but the > > other languages fail. > > > > I don't know how to solve this, except using an absolute reference to > > the CSS file in the /english/News/news.rdf.in instead of the $(HOME) > > variable. > > I'll skip this for now, to concentrate on the topic I've debugged this > evening; this might be related though! > > > 1.2. */sitemap.*.html (all languages) > > > > I guess it's the same problem (that the $(HOME) variable is used and > > interpreted wrongly with the new make or wml), but this file and how it > > is built is more cryptic for me so I wouldn't know how to start. > > > > The sitemap would be completely broken until this issue is fixed, if > > we migrate www-master to buster :/ > > > > Help needed! > > For the record, we're talking about: > https://salsa.debian.org/webmaster-team/webwml > > The problem can be triggered with: > make -C english sitemap.en.html > > Another file in the same directory can be obtained with: > make -C english index.en.html > > > OK, so I've spent some time on this. Based on the HOME mention, I tried > to switch it from `-D HOME~.` to `-D HOME=.` in english/.wmlrc but that > wasn't sufficient. I had to turn *all* such defines in that file from > `~` to `=` to get a reasonable sitemap. > > The wml_intro.7 manpage quickly explains the difference between both, > but that seems to be happening in passes 2 and 3; english/sitemap.wml is > one of the only files were pass protection is used, but that turned out > to be a red herring… > > > Adding the `-v2` flag to the `$(WML)` calls in english/Makefile made the > issue apparent: as early as pass 1, we have different parameters being > sent to wml_p1_ipp between stretch (2.0.12) and buster (2.12.2), among > which: > > * stretch: > > "-DBUGS=Bugs" > "-DINTRO=intro" > > * buster: > "-DBUGS=../english/Bugs" > "-DINTRO=../english/intro" > > for our english/sitemap.wml > > BUT > > that's not the case for index.en.html, built from english/index.wml! > > At this point, I suspected the origin of the change in behavior was the > path to the input file: > > $(WML) … index.wml is OK > $(WML) … ../english/sitemap.wml is not OK > > because the latter triggers the insertion of `../english/` in lots of > places (defined with `~` instead of `=`) with 2.12.2, which was not the > case with 2.0.12. > > > Dropping the ../english/ prefix for sitemap.wml leads to a reasonable > diff for the English sitemap (sitemap.en.html): > > --- stretch.en.html 2020-06-08 00:07:43.916768223 +0200 > +++ buster.en.html
Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster
Hi Shlomi, Shlomi Fish wrote: > 2. The newest release of wml is 2.28.0 (see > https://github.com/thewml/website-meta-language/releases ) I know. > while Debian sid is stuck at 2.12.x (see > https://packages.debian.org/sid/wml ). Yes, as I didn't get any newer releases (up to 2.24) to build properly anymore. You can see my tries here: https://salsa.debian.org/debian/wml/-/tree/2.20.4-pkg-incomplete (ignore the version in the branch name, I didn't expect this to last several upstream releases). IIRC I had test suite failures. Need to check 2.28 again. (And yes, I know, I haven't filed an upstream bug report yet — still haven't figured out what exactly is the cause for the failures.) > I'd rather not support such an old release, It's not about Debian Unstable, it's about the WML version in current Debian Unstable (which only happens to be the same upstream version as in Debian Unstable for the reasons mentioned above) and Debian (well, I) will support this until the EoL of Debian 10 Buster. > so if the new version still exhibits some > regressions, please send a failing testcase to > https://github.com/thewml/website-meta-language/tree/master/src/wml_test and > I'll try to fix it. Will do — as soon I get it building again. > Converting some of my sites away from wml has shortened their build times > considerably. But are they as flexible as before while still being statically compiled? I doubt. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster
Hi again, Axel Beckert wrote: > > I'd rather not support such an old release, > > It's not about Debian Unstable, it's about the WML version in current > Debian Unstable (which only happens to be the same upstream version as of course this should have been "Debian Stable", not "Debian Unstable again. > in Debian Unstable for the reasons mentioned above) and Debian (well, > I) will support this until the EoL of Debian 10 Buster. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster
Hi Axel, On Thu, 11 Jun 2020 13:51:28 +0200 Axel Beckert wrote: > Hi Shlomi, > > Shlomi Fish wrote: > > 2. The newest release of wml is 2.28.0 (see > > https://github.com/thewml/website-meta-language/releases ) > > I know. > > > while Debian sid is stuck at 2.12.x (see > > https://packages.debian.org/sid/wml ). > > Yes, as I didn't get any newer releases (up to 2.24) to build properly > anymore. You can see my tries here: > https://salsa.debian.org/debian/wml/-/tree/2.20.4-pkg-incomplete > (ignore the version in the branch name, I didn't expect this to last > several upstream releases). > > IIRC I had test suite failures. Need to check 2.28 again. (And yes, I > know, I haven't filed an upstream bug report yet — still haven't > figured out what exactly is the cause for the failures.) > Ah - thanks for the update. I guess I can try building the package myself in a VM/container. For the record, the build and tests pass fine in travis-ci/ubuntu bionic , locally on fedora and mageia, on the mageia build system, and on appveyor/mswin10/cygwin . > > I'd rather not support such an old release, > > It's not about Debian Unstable, it's about the WML version in current > Debian Unstable (which only happens to be the same upstream version as > in Debian Unstable for the reasons mentioned above) and Debian (well, > I) will support this until the EoL of Debian 10 Buster. > ok. > > so if the new version still exhibits some > > regressions, please send a failing testcase to > > https://github.com/thewml/website-meta-language/tree/master/src/wml_test and > > I'll try to fix it. > > Will do — as soon I get it building again. > I'll try to help. > > Converting some of my sites away from wml has shortened their build times > > considerably. > > But are they as flexible as before while still being statically > compiled? I doubt. > They are still "statically compiled" (or generated: https://github.com/shlomif/shlomif-tech-diary/blob/master/static-site-generators--despair.md ), and I verified that they generated the same output before and after using "diff -u -r", html-minifier and other tools. Template Toolkit is fairly flexible and has fewer "WTF?" surprises than wml, as I discovered some misrendered output during the conversions. There may be some features that only wml has and TT doesn't, but I think the benefits outweigh the drawbacks. > Regards, Axel -- Shlomi Fish https://www.shlomifish.org/ Objective Visual Turbo Global jIronOpenPerl++.NET™ Enterprise Edition♭ Professional Home Premium Ultimate 64-bit Single-user. — based on a Freenode #perl conversation ( https://is.gd/cCUBY2 ) Please reply to list if it's a mailing list post - https://shlom.in/reply .
Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster
Hi Shlomi, [taking Cyril and Laura out of the loop] Shlomi Fish wrote: > > IIRC I had test suite failures. Need to check 2.28 again. (And yes, I > > know, I haven't filed an upstream bug report yet — still haven't > > figured out what exactly is the cause for the failures.) > > Ah - thanks for the update. I guess I can try building the package > myself in a VM/container. For the record, the build and tests pass > fine in travis-ci/ubuntu bionic , locally on fedora and mageia, on > the mageia build system, and on appveyor/mswin10/cygwin . Yeah, another reason for not having it reported upstream is that I'm not yet sure if one of the Debian patches is the culprit. Regarding Travis CI: IMHO its value is quite limited by the fact that Travis is nearly always two or more years behind the latest Ubuntu LTS release. (Actually I'm kinda surprised that they in the meanwhile managed to support 18.04. The last time I looked (IIRC a few months ago around the 20.04 release) they were still on 16.04. > > Will do — as soon I get it building again. > > I'll try to help. Appreciated, but I would kinda feel bad in case one of the Debian patches will be identified as the culprit and someone else had to do my work. :-) > > > Converting some of my sites away from wml has shortened their > > > build times considerably. > > > > But are they as flexible as before while still being statically > > compiled? I doubt. > > They are still "statically compiled" (or generated: > https://github.com/shlomif/shlomif-tech-diary/blob/master/static-site-generators--despair.md > ), and I verified that they generated the same output before and > after using "diff -u -r", html-minifier and other tools. Template > Toolkit is fairly flexible [...] Ah, TT. Oh well, from my point of view, TT always felt too generic to me. I had the feeling that I'd have to write a lot of the infrastructure for static compiling that WML already offers (mainly wmk, but also some of the passes like splice), myself. So I never considered it to be a WML replacement but rather something that is on the same level as e.g. Embperl.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster
Hi Axel! You can find my attempt to fix the debian build here: https://www.shlomifish.org/Files/files/code/wml.debian-shlomify-1.diff The sed addition to debian/rules seems to improve matters, but the restoration of p9_slice (to fix loading SliceTermParser.pm ) gives dpkg-source a fit. I really find the debian gbp stuff puzzling. here is the script i used: https://www.shlomifish.org/Files/files/text/docker-wml-debian-perl-v0.1.0.txt On Thu, 11 Jun 2020 17:00:42 +0200 Axel Beckert wrote: > Hi Shlomi, > > [taking Cyril and Laura out of the loop] > > Shlomi Fish wrote: > > > IIRC I had test suite failures. Need to check 2.28 again. (And yes, I > > > know, I haven't filed an upstream bug report yet — still haven't > > > figured out what exactly is the cause for the failures.) > > > > Ah - thanks for the update. I guess I can try building the package > > myself in a VM/container. For the record, the build and tests pass > > fine in travis-ci/ubuntu bionic , locally on fedora and mageia, on > > the mageia build system, and on appveyor/mswin10/cygwin . > > Yeah, another reason for not having it reported upstream is that I'm > not yet sure if one of the Debian patches is the culprit. It seems like this is the case. > > Regarding Travis CI: IMHO its value is quite limited by the fact that > Travis is nearly always two or more years behind the latest Ubuntu LTS > release. (Actually I'm kinda surprised that they in the meanwhile > managed to support 18.04. The last time I looked (IIRC a few months > ago around the 20.04 release) they were still on 16.04. > Yes, you can run docker containers in travis. > > > Will do — as soon I get it building again. > > > > I'll try to help. > > Appreciated, but I would kinda feel bad in case one of the Debian > patches will be identified as the culprit and someone else had to do > my work. :-) No worries. > > > > > Converting some of my sites away from wml has shortened their > > > > build times considerably. > > > > > > But are they as flexible as before while still being statically > > > compiled? I doubt. > > > > They are still "statically compiled" (or generated: > > https://github.com/shlomif/shlomif-tech-diary/blob/master/static-site-generators--despair.md > > ), and I verified that they generated the same output before and > > after using "diff -u -r", html-minifier and other tools. Template > > Toolkit is fairly flexible [...] > > Ah, TT. Oh well, from my point of view, TT always felt too generic to > me. I had the feeling that I'd have to write a lot of the > infrastructure for static compiling that WML already offers (mainly > wmk, but also some of the passes like splice), myself. So I never > considered it to be a WML replacement but rather something that is on > the same level as e.g. Embperl.) > Perhaps. > Regards, Axel -- Shlomi Fish https://www.shlomifish.org/ UNIX Fortune Cookies - https://www.shlomifish.org/humour/fortunes/ Fortran - there isn’t a way to do it... oh wait! Now there is. — https://www.shlomifish.org/humour/ways_to_do_it.html Please reply to list if it's a mailing list post - https://shlom.in/reply .
Re: Broken links policy/monitoring
On Thu, Jun 11, 2020 at 04:45:15AM +, Paul Wise wrote: > On Wed, Jun 10, 2020 at 4:51 PM Ryan Nowakowski wrote: > > Do we currently actively monitor the site for broken links? > > I don't know if anyone looks at the logs, but: > > https://www-master.debian.org/build-logs/urlcheck/ Thanks Paul. I searched a bit and couldn't find the urlcheck python script. Anyone know where I get a copy to play with?
Re: Broken links policy/monitoring
Hi Ryan El 11/6/20 a las 23:09, Ryan Nowakowski escribió: > On Thu, Jun 11, 2020 at 04:45:15AM +, Paul Wise wrote: >> On Wed, Jun 10, 2020 at 4:51 PM Ryan Nowakowski wrote: >>> Do we currently actively monitor the site for broken links? >> >> I don't know if anyone looks at the logs, but: >> >> https://www-master.debian.org/build-logs/urlcheck/ > > Thanks Paul. I searched a bit and couldn't find the urlcheck python > script. Anyone know where I get a copy to play with? > You can find the scripts here: https://salsa.debian.org/webmaster-team/cron/-/tree/master/urlcheck Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Re: Broken links policy/monitoring
On Thu, 2020-06-11 at 16:09 -0500, Ryan Nowakowski wrote: > Thanks Paul. I searched a bit and couldn't find the urlcheck python > script. Anyone know where I get a copy to play with? https://salsa.debian.org/webmaster-team/cron.git -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
