Mailman 3 - moin-devel

semrush not working
by IPT O'brian July 22, 2025

July 22, 2025

kvndnb

1 0

Moin 2.0.0b3 released
by Roger Haase May 24, 2025

May 24, 2025

Moinmoin 2.0.0b3 has been released on https://pypi.org/project/moin/#historyand https://github.com/moinwiki/moin/releases. See https://moin-20.readthedocs.io/en/latest/,use https://github.com/moinwiki/moin/issues to report bugs.

1 0

Source of graphical smileys
by PostRox April 5, 2025

April 5, 2025

Hello, I'd like to know what the source of the images used for the graphical smileys is. More specifically, the source of the information "smiley" displayed with the {i} markup. Most of them look like they were taken from Tango, an icon set that was developed in the late 2000s. I want to obtain higher resolution images of the information "smiley". But when I get the icons from the archive, since the Tango project stopped development 16 years ago, the information icon designed by them is completely different. I'm asking you this because this icon is used nowadays just by the MoinMoin wiki (at least the only project I've found that uses it). Do you remember what the source of this icon is? P.S.: I posted this in the development mailing list because the theming and icons used are part of the development. But if you believe this would better fit in the user mailing list, I'll gladly ask it there. Thanks in advance.

1 0

Moinmoin 2.0.0b2 released
by Roger Haase March 3, 2025

March 3, 2025

Moinmoin 2.0.0b2 has been released on https://pypi.org/project/moin/#history and https://github.com/moinwiki/moin/releases. See https://moin-20.readthedocs.io/en/latest/, use https://github.com/moinwiki/moin/issues to report bugs.

1 0

Message from Lucas Szybalski
by Lukasz Szybalski Dec. 24, 2024

Dec. 24, 2024

Hello Team As we get into the end of 2024 I figured I send this message out to express Thank You for everyone's contributions. The year has been moving fast and I know there are efforts to improve moin moin. I wanted to take a minute and talk about the happiness it brought me, the release of moin version 2.0 and how the attention of the developers before was split between 1.x and 2.x and now we are finally onto one version again. Each of them being active felt like diluting the power of our community. Happy to hear that we may now focus our force of every contribution towards one common goal version 2.0 and beyond. On the topic of the evolution of wiki. Over years of my career I've learned one thing, we love to write software, but we also need to pay attention to what users want. In a typical for-profit organization this would translate into a tool for decision making: "enable solutions that a customer is willing to pay for". In our volunteer work we need to embrace one part of this decision making process i.e. our need to understand the direction of what users want. The wikis way have evolved, and I want to discuss a few topics that come to mind when it comes to evolution of what was and what is. This evolution is seen across the whole wiki-like software category. Evolution of git. Recently moin has moved some of its documentation to github, and while reviewing documentation I found that editing the page, logging in with github, having my change being reviewed by admin, and accepted within 24h, and pushed to prod was powerful. Felt my contribution was recognized and felt the power of git controlling the change. I think there is a power of using git as the engine of commits. I think it could allow possible decomposition of elements and greater diversity of implementations assuming it can scale to wiki type # of commits. The git system has been tested for years and has taken over how anyone works together. There is a great amount of tooling and understanding of its processes and we could take advantage of it inside the wiki process. Evolution in private and public. I find that the solutions are similar yet applied differently and there can be activities that can allow synergy between the two. One solves a problem for the other and the other solves a problem for first. Both feeding each other and expanding the reach. Before I proceed I wanted to express that I feel the focus is a key, and I think the focus for our development community would be to increase our user base at the cost of our pride as being one holistic solution. I don't say that lightly, It took some amount of time to realize that. Evolution in private and public continued Login with (google, apple, AD, microsoft, github, twitter, linkedin) so many solutions I wish I was able to say I'm able to login my debian.org or linux.org account or some other open source entity that has my identity ,profile, my public encryption key but I'm not sure I find one that is not sponsored by a for profit corporation. A key lesson we need to pay attention to is the fact that for profit companies that provide this service they could allow us to increase our userabase. One key area I can see our growth is within a corporation (from small business you might be running <5 employees * million of them OR companies with 100 employees * hundreds of thousands of them. I think we have the potential to gain a large market share of users who not only develop but also use the knowledge provided on their wikis. Maybe it's specific to that group. Embedding forms, sheets, dashboards or other. There are so many things you can share posts of, whether sharing your twitter post, your facebook marketplace, your linked in profile, sharing has become a key idea of spreading the message. Finding the most simplistic way to share is a challenge I leave with you. Looking forward to your ideas on how users can share each article/contribution or page in general with others. Community joining in social. This has developed into its own thing, right? How many of you are following someone, liking tweets, joining discord, slack channels to engage with others. I think building a community around an area /group / page would bring a large volume of users. What this really allows one to do is exposing your ideas/creativity in wiki, and having 100x of others either join you on your journey by joining the page as subscriber, or maybe a contributor, or maybe viewers or commenter. There are many different ways to contribute, and solving a challenge of making it easy for other people to join the page and start engaging can only be solved by the open source community; a place where each of our ideas can be mixed and remixed into amazing solutions. Push notifications - I think our version 1 of a built in feature called 'change notification' was a great beginning, but this has evolved into people receiving notifications in various formats, channels, and frequency. >From being notified of every change, to being notified of a new page, new post, new comment, or when someone pings me. Why limit myself? If I already said I want to engage with the page, then bring the news to me in whatever channel I want it to. That is the evolution of push notifications. Is getting notified on my phone from all the social media unhealthy, yes, but I have no problem muting all of them except for phone calls, sms, and this one important wiki page :). I really care about it so let's give users the ability to engage and get notified. Routing and functions With every healthy group (your class, your family, a group you get paid to support, a volunteer group, your favorite crossfit class, etc), there is a directory, there is contact us, report issues, helpdesk, learning, how to contribute, all these are "functional pages that allow some action to happen. Could this routing function page be subscribing me, or maybe signing me up to the next user group meeting that will be held in 2 weeks and adding me to meeting invite, or maybe learning will notify me of a change of specific thing on a page, or I have a question related to content on the page. All sorts of requests going back and forth could be solved by these helper function pages. Can I get a badge for that, or a token for doing the contribution work. How can we incorporate the "function-do" into our everyday wiki usage? As with any software, plugins allow the ecosystem to grow. From stores with apps, to plugins, themes free and paid, to plugins that solve seo challenges, to plugins that allow forms submissions ,payments, shipping ,etc. Finding a way to allow plugins enablement could lead to a lot of success for our project. I think building infrastructure to enable it, and exposing the api in documentation that is easily consumed and developed on, could speed up the adaptation growth and again provide synergy in our user growth and community ecosystem that supports it. That is the evolution I wanted to speak to you about today. I hope this message finds you well and my intent is that it's mutually beneficial for everyone's side. I wanted to emphasize a key point, focusing our efforts is a key, I would rather see all developers of all wikis come together in implementing changes that users want, then seeing everyone reinvent the same existing feature in a new function. We need to evolve, as new younger developers are joining we need to shine a light on the issues worth pursuing. We need them to work on things users want them to resolve. We need to give them guidance on how to do and accomplish it, give ourselves and others support and badges for doing the work. We can't do it ourselves but we can do it together. That's the beauty of true open source. We get to solve problems that no one else can. I look forward to your contribution in the next 90 days and the whole 2025. Thank you -- Lucas Szybalski

1 0

Debian packages problem: traceback in themes/__init__.py" line 831: AttributeError
by Ulrich B. Sept. 12, 2024

Sept. 12, 2024

Hi Paul, in April you posted following error on the moin-user mailing list: > I now get the following errors when deploying a wiki using Apache and mod_wsgi: > > File "/usr/lib/python3/dist-packages/moin/themes/__init__.py", line 831, in setup_jinja_env > "item_name": request.view_args.get("item_name", ""), > ^^^^^^^^^^^^^^^^^^^^^ > AttributeError: 'NoneType' object has no attribute 'get' > > Using the built-in Web server with "moin run" works fine, however. If you still need support, may I ask you to send me more details on how to reconstruct this error? What version of Debian are you using and where can I find the moin package for testing? Regards, Ulrich

2 7

Moin 1.9 & 2: Link to fraudulent website in your help pages, action required
by Sebastian Wagner Aug. 22, 2024

Aug. 22, 2024

Dear Moin community, Moin's default intermap.txt contains a InterWiki link for the usemodwiki. Although usemod[.]com has been replacedby usemod[.]org by it's owners, a Vietnamese *online gambling* website now uses .org, the original domain, which is still part of the intermap.txt. As the help page 'HelpOnProcessingInstructions' contains a link using the usemodintermaplink, *all Moin-instances*contain a link to that fraudulent website. For Moin2, the current git HEAD contains a fix; for Moin 1.9, the fix has not yet been merged. However, *updating your instance is insufficient*, as the intermap.txt is a setting per instance. You can use the following command at your own risk (adapt if needed) to update the file: sed -i -e 's#usemod\.com/cgi-bin/mb\.pl?InterMapTxt#usemod.org/cgi-bin/mb.pl?InterMapT…' -e 's#www\.usemod\.com/cgi-bin/mb\.pl?#meatballwiki.org/wiki/#' -e 's#usemod\.com/cgi-bin/wiki\.pl#usemod.org/cgi-bin/wiki.pl#' intermap.txt And similar, the website httpX://parawiki[.]org/ promotes a Thai gambling service, so it can be removed as well: sed -i '/parawiki.org/d' intermap.txt A significant number of thelinks in the intermap.txt are outdated, these *currently*don't pose an equal fraud or security risk. We recommend only keeping those entries in the intermap.txt that are actually needed in your wiki. Best regards and keep safe Sebastian More details: * Moin2 Issue: https://github.com/moinwiki/moin/issues/1729 * Moin2 Merge Request for usemod: https://github.com/moinwiki/moin/pull/1731 (merged, unreleased) * Moin2 Merge Request for parawiki: https://github.com/moinwiki/moin/pull/1732 (unmerged, unreleased) * Moin1.9 Issue: https://github.com/moinwiki/moin-1.9/issues/100 * Moin1.9 Merge Request for usemod: https://github.com/moinwiki/moin-1.9/pull/101 (unmerged, unreleased) * Moin1.9 Merge Request for parawiki: https://github.com/moinwiki/moin-1.9/pull/102 (unmerged, unreleased) -- Sebastian Wagner <sebastian.wagner(a)intevation.de> | https://intevation.de Intevation GmbH, Osnabrueck, DE; Amtsgericht Osnabrueck, HRB 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter

1 0

Moinmoin 2.0.0b1
by Roger Haase Aug. 15, 2024

Aug. 15, 2024

Moinmoin 2.0.0b1 has been released on https://github.com/moinwiki/moin/releases. See https://moin-20.readthedocs.io/en/latest/,use https://github.com/moinwiki/moin/issues to report bugs. This release is the same as that uploaded to https://pypi.org/project/moin/#historya week ago. Roger Haase

2 1

Re: [moin-devel] moin-devel Digest, Vol 23, Issue 8
by Reimar Bauer Sept. 28, 2023

Sept. 28, 2023

On Fri, Sep 22, 2023 at 6:00 PM <moin-devel-request(a)python.org> wrote: > Send moin-devel mailing list submissions to > moin-devel(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/moin-devel > or, via email, send a message with subject or body 'help' to > moin-devel-request(a)python.org > > You can reach the person managing the list at > moin-devel-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of moin-devel digest..." > > > Today's Topics: > > 1. Re: Moin2 - Create new theme (Paul Boddie) > 2. Re: Moin2 - Create new theme (Ulrich B.) > 3. Re: Moin2 - Create new theme (Christoph Klassen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Sep 2023 18:03:39 +0200 > From: Paul Boddie <paul(a)boddie.org.uk> > To: moin-devel(a)python.org > Subject: Re: [moin-devel] Moin2 - Create new theme > Message-ID: <2111020.dz6aNmVp7Z@jason> > Content-Type: text/plain; charset="us-ascii" > > On Thursday, 21 September 2023 16:16:00 CEST Christoph Klassen wrote: > > > > And which icons are you using? Are they from Font Awesome? > > They appear to be, yes. In the Debian package, the python3-xstatic-font- > awesome package is a dependency which depends on fonts-font-awesome. > > I think the Debian package may need to incorporate a patch to upstream > Moin > sources because a stylesheet file in src/moin/templates/base.html called > all.css is specified, whereas the Debian fonts-font-awesome package > doesn't > have such a file. Instead, it seems that font-awesome.css might be the > appropriate file. > > Although Debian unstable provides Font Awesome 5.x, which has the all.css > file > upstream, Debian appears to have maintained compatibility with 4.x. > Indeed, > the version of this package is given as... > > 5.0.10+really4.7.0~dfsg-4.1 > > So maybe there will be an upgrade to this package at some point. > > Paul > > > > I had builded last year the V6.2.1 on Pypi, compared to the old 4.1.0, this was a big change https://github.com/xstatic-py/xstatic-font-awesome/pull/1/files Likly in november I will update this to 6.4.0 or newer Reimar

1 0

Re: [moin-devel] Debian packages (Re: moin2 release with core functionality)
by Paul Boddie Sept. 22, 2023

Sept. 22, 2023

On Tuesday, 12 September 2023 22:56:26 CEST Nicholas D Steeves wrote: > > Paul, you're already forwarding patches, maintaining a package, and > deploying it using a not-particularly-well-known apt_repo-in-Salsa > method, so I think a Debian team context would be an asset for those > times when--for example--you want to take a holiday :) Also would mean > that sysadmins who use downstreams like Ubuntu would also be able to > benefit from your work, and this seems like it would reinvigorate Moin > usage in the wild. The moin-team group was Steve McIntyre's initiative, and publishing out of Salsa is just a workaround at present, but I agree that something more substantial is probably needed. [...] > sbuild-debian-developer-setup is the easiest way that I know to get a > clean chroot: > > https://manpages.debian.org/bookworm/sbuild-debian-developer-setup/sbuild-d > ebian-developer-setup.1.en.html > > Using sbuild will also do some minor fuzzing (eg: packages must declare > all needed dependencies and must only write to safe locations during the > package build) Yes, I currently use gbp as follows: gbp buildpackage --git-debian-branch=debian/master \ --git-upstream-tag='upstream/%(version)s' \ --git-builder=sbuild I overlooked that sbuild might provide tools that are usable enough for more general activities, and I might even try this out myself! Thanks once again for the suggestions! Paul

2 2