Re: A policy on use of AI-generated content in Debian
Hi, >> Generative AI tools **produce** derivatives of other people's copyrighted >> works. > >They *can* do that, but so can humans (and will). Humans look at a >product or code and write new code that sometimes resembles the >original very much. Can I ask the LLM where it was probably inspired? Can I show the LLM another work and ask it whether there might be a chance theu got inspired by it (and get a different answer than that it probably sucked in everything, so yes)? Is there a chance that the LLM did not only read some source code, but also had friendly interactions with the author? Admittedly, at that point, we get into philosophical questions, which I don't consider any less important for free software. -nik
Re: A policy on use of AI-generated content in Debian
Hi, >It's just another tool that might or might not be non-free like people >using Photoshop, Google Chrome, Gmail, Windows, ... to make >contributions. Or a spamfilter to filter out some. That's entirely not the point. It is not about **the tool** being non-free, but the result of its use being non-free. Generative AI tools **produce** derivatives of other people's copyrighted works. That said, we already have the necessary policies in place: * d/copyright must be accurate * all sources must be reproducible from their preferred form of modification Both are not possible using generative AI. -nik
Re: Will nala be in software soon?
>While I'd have liked to jump onto the parade to bash M$ GitHub, the project is >actually hosted on GitLab ... ...which makes the main argument even worse...
Re: Will nala be in software soon?
>Nala is a github project I do hope it is primarily a free software project, instead of its primary identity being a GitHub promotion project.
Re: [RFC] Extending project standards to services linked through Vcs-*
Hi Ángel, > On 2023-08-21 at 17:00 +0200, Dominik George wrote: > > But, I want to go one step further and think about who is invited to > > do what. If *some* people are invited to contribute through the VCS, > > and others are not, this does not fulfill the requirement of > > equality. So, if we invite one person to contribute through a VCS > > platform, we should invite everyone to do so. > > Is this really an issue? > > These terms make perfect sense but, isn't everyone pretty much doing it > already? Are there cases where *some* non-maintainers are invited to > contribute through the VCS while others are not? (*) Yes, my proposal is based on two very specific encounters, where contributors were more or less pushed to use the VCS instead of the BTS. I was myself in another case where I wanted to contribute to a package and found out that it is maintained on GitHub, but I did not get to find out whether I could have contributed without using GitHub. However, pull requests were accepted on GitHub, which fulfills my description of "being invited", and GitHub having exclusive terms also of "other being not invited". So yes, it is a real issue, albeit a corner case. > Rather, I think the problem statement would be that people don't know > the "right way to contribute" to the package. > > Some maintainers will prefer the BTS. > Others will like to receive patches against the VCS. Or pull requests. > Against the master branch. Or main. Or devel. None of them, against the > last stable. > The maintainer may internally use GitHub issues. Or a Launchpad > project. Or use any of many other systems to track issues. > > > Not knowing the procedure. [for this specific package] → Trying to > contribute in some way that seemed appropriate → Turns out it isn't → > Failure. That's not the problem at hand. The problem at hand is where the maintainer thinks the "proper" way is using the VCS, and chooses a VCS that is less inclusive than Debian systems. It does not help to tell the contributor that the VCS is the proper way to contribute, because they cannot use it. And that's exactly what I would like to prevent. > A typical case would be a maintainer which has no problem accepting > contributions through GitHub. It just happens not to notice issues > opened there (yet contributors think they did what was expected), and > checks them only once a year. > For the argument's sake, let's suppose that the maintainer reviews theGitHub > issues and pull requests on New Year's Eve, processing everything opened in > the last year, by anyone. > > It doesn't break the equality terms. Everyone contributing through > GitHub is treated the same. But it is nevertheless a Bad experience. > > (It may be that "maintainers must ensure that the VCS is accessible > under the same conditions as the Debian BTS to anybody" was expected to > cover "They must look at issues opened in GitHub as often as they look > at the BTS" as well? It's nt clear what "under the same conditions" was > trying to cater) I don't think that's part of the argument. My request does not make any assumptions on how often and when and why a maintainer handles contributions. It only asks for offering the same access conditions to the used platforms to everyone. > > > *Disabling* the embedded VCS means for contribution is one way to > signal it's not the expected way, but only incidentally. > > > I don't know what would be the proper way to mark the expected way to > contribute. Ideally, a good old "CONTRIBUTING" file, but that might be > considered too cumbersome and barely followed. Adding a field listing > the preferred (or allowed) way to contribute would do, but that would > mean adding yet another field. Well, the consequence of my proposal, if we take it further, would be: If a maintainer lists their VCS in the source package, then they need to accept people using it. And if they accept people using it, they must ensure that everyone can do so under the same conditions. Maintainers of course MUST always accept bugs and patches (accept as in receive and consider, not merge into their package) through the BTS. We have this provision in place, and I have no intentions to change that. -nik signature.asc Description: PGP signature
Re: [RFC] Extending project standards to services linked through Vcs-*
Hi, > As an aside, unless something has changed very recently, GH does not > give you a way to disable PRs (issues yes but not PRs). > > If that has suddenly become possible, I have around a thousand > projects I help maintain upstream on a non-GitHub (open source) code > forge and would love to have a way to disable PRs on all the GH > mirrors of those. For now we run a periodic bot that scans for open > pull requests and closes them with a comment telling people where to > find our contributor workflow documentation. Thanks for the hint! You are indeed right – disabling pull requests is not possible on GH. In any case, making it prominently clear that pull requests are not the primary way of contribution, would be sufficient for the case in point. -nik signature.asc Description: PGP signature
Re: [RFC] Extending project standards to services linked through Vcs-*
Hi, On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote: > Dominik George writes: > > > For the GitHub case, the problematic terms would be that in order to > > register for a GitHub account, users must be at least 13 or 16 years old > > (depending on the jurisdiction) ant must not live in a country under US > > embargoes. > > This implies that Salsa is happy to create accounts for people under the > age of 13, since the implicit statement here is that Debian's own Git > hosting infrastructure is less excluding than GitHub. > > That's a somewhat surprising statement to me, given the complicated legal > issues involved in taking personal data from someone that young, so I want > to double-check: is that in fact the case? That is, in fact, the case. And no, it's not not legally complicated to collect personal data from children. If we, for now, only look at COPPA and GDPR, the laws relevant for the US and EU, respectively, the situation is: * You can accept consent from children, if: * it can be, objectively, assumed that they can overlook the consequences of the data collection → we can assume that, if someone sucessfully contributes to a Debian package, they are knowledgable enough, given that Salsa only collects a pseudonym and an e-mail address * you don't use the data for marketing or profiling purposes → we don't do that * you don't direct commercial advertisements at children → we don't do that * you don't explicitly advertise your service to children (as in, promising them a benifit exceptionally attractive for children) → we don't do that Even if we did one of the above things, we'd still be able to accept children if they have parental consent, which is a bit tricky (but, should we get to this at some point, be outsourced to a trusted partner, like Teckids, who has expertise in that field). If we get to this point, I will certainly fight to accept children with parental consent, even if it implies some work. GitHub and a lot of other services, however, in addition to not being able to allow children without parental consent, also don't accept them *with* parental consent. As it stands, Salsa (and a lot of other Debian services) are not GDPR-compliant because they do not have a privacy statement making the above clear, but while related, let's not mix that into this thread. Cheers, Nik signature.asc Description: PGP signature
[RFC] Extending project standards to services linked through Vcs-*
Heisann, [ for reference, the general discussion was held in 2019 already, in a slightly ] [ too big context [3]. ] as many of you will know, I am heavily involved in tearing down obstacles in the way of contributing to free and open source software (with a focus on very young people). As a Debian Developer, I am proud to use and contribute to a distribution that is among the top projects in that regard, by… * …depending almost purely on its own infrastructure * …not caring the least about any personal attributes of contributors * …having policies in place that are (legally) acceptable by virtually everyone, only limited by legislation, if at all * …putting great freedom in the choice of tools into the hands of contributors * …actively fostering education and young people However, there is one aspect I sometimes find to cause a break in this outstanding pattern: The ever so often discussed maintenance of source packages in (Git) repositories (for the sake of simplicity, I am ignoring non-Git VCSs here). Basically, as a quick summarization, the rules for VCS usage are: * Maintainers are free to use a VCS for packaging, or not * Maintainers are free to choose any VCS they like * VCSes can optionally be linked to source packages through the VCS-* fields [1] * Policy somewhat requires VCSes that are linked in VC-* fields in source packages to be pblicly accessible * Maintainers must use the official contribution channels (i.e. the BTS) even if they use a VCS [2] In essence, we could, somewhat polemically, conclude that: Packages may be developed in a VCS repository for the maintainers' delight, but these repositories are not an official part of the package lifecycle from a distribution perspective Generally, not having a clear policy on that VCS package maintenance means is, in my opinion, one of the major obstacles when trying to contribute to Debian. Part of this is the freedom maintainers have in using these tools. This results in variosu different approaches, two of the rather problematic ones including using a VCS, and then frowning upon contributions outside the VCS, and using a VCS, but then not allowing contributors to use the VCS as well. In contrast to the huge discussion in 2019, I would like to propose a softer set of policies to tackle this problem, with the ultimate goal of allowing collaboration for everyone indeendent of whether a VCS is used or not. Besides the social challenges that come with maintainer decisions, the measurable aspect is whether contributors can collaborate on the VCS or not, if they want to and if the maintainer generally accepts contributions there. For the current picture, here is a summary of where VCS repositories linked to source packages are currently hosted: Debian infrastructure 181969 GitHub.com3898 GitLab.com 334 A full ranking of the VCS hosts can be acquired using UDD with a query like select substring(vcs_url from '(?<=://)[^/]+(?=/)') as domain, count(vcs_url) as count from sources group by domain order by count desc; The issues with GitHub as an example were discussed from a freedom perspective in 2019 in a sub-thread [4] – the essence being "GitHub is non-free, noone should hae to use non-free services to contribute to Debian". Instead, I'd rather like to examine the situation from an equlity perspective, and from a perspective of extending the general tenor of DFSG (in particular, point 5) [5] to other terms besides licenses. For instance, that would be: "The terms of use must not discriminate against any person or group of persons." The essential doctrine would be that we, as the Debian community, must not impose any limitations on who can contribute, in addition to those potentially imposed by governing laws, and that we must ensure that all people that can participate at all can do so under the same preconditions. For the GitHub case, the problematic terms would be that in order to register for a GitHub account, users must be at least 13 or 16 years old (depending on the jurisdiction) ant must not live in a country under US embargoes. Now, some will argue that it's still optional to use the VCS, and that anybody who wants to contribute to a package can unconditionally do so using the BTS, even if the maintainers use a VCS repository. That would, of course, require a stric policy placing all maintainers under the obligation to accept contributions through the BTS, even if they use a VCS. But, I want to go one step further and think about who is invited to do what. If *some* people are invited to contribute through the VCS, and others are not, this does not fulfill the requirement of equality. So, if we invite one person to contribute through a VCS platform, we should invite everyone to do so. Now for the concrete implementation of this idea: I propose to
Re: Questionable Package Present in Debian: fortune-mod
Hi Marvin, >This is simply and blatantly incorrect. Debian is a distribution. To some, that is the same. If you think describing Debian as an "operating system", then for a start, you should go and propoae to update the banner on the front page of https://debian.org/ -nik
Re: Questionable Package Present in Debian: fortune-mod
>The mission you have chosen for yourself, then, is to identify all those >things in the Debian distribution that are not constitutive of an >operating system. That is a major part of the work of a Debian Developer, and the ftp-master team. Packages are evaluated for eligibility to enter the distribution all the time, we had times where every new binary package was frowned upon due to resource constraints on the archive. If I uploaded fortunes-natureshadow because I think my favourite quotes are worth being shipped with an operating system, I am pretty sure it would get rejected. There is no reason to handle fortunes-off any different. -nik
Re: Questionable Package Present in Debian: fortune-mod
> So, let's at least be consistent. Totally agree with that. Debian is not a collection of harmful content, it is an operating system. But, unfortunately, there are too many people in the project who think, in the name of "free speech", protecting racists, nazists, and anarchists is more important than protecting PoC, jews, or other minorities. -nik
Re: Fortunes-off - do we need this as a package for Bookworm?
> Right, and has has been discussed before (more times than can be > counted, most likely) having some sort of content does not imply that > the ideology itself is promoted. The presence of the texts of the > Torah, the Christian Bible, the Quran, and other holy books in Debian > does not mean that Debian as an organization supports all of the various > ideologies entailed therein. You should probably take a history book and look up again what the author of Mein Kampf did, and compare that to what the authors of the other texts you mention did. If you succeed in drawing any comparison between Adolf Hitler and any of the evangelists and prophets who rote the bible, or mostly any other authors of any other books, repeat the procedure. If that still doesn't help, please take a trip to one of the concentration camps that are now museums. Then, should you still find that murdering 6 million Jews in what is known as the Holocaust can be compared to ideas of anarchism, Christianity or the Islam, I fail to assume good faith. -nik signature.asc Description: PGP signature
Re: Fortunes-off - do we need this as a package for Bookworm?
> The specific query was about Nazi quotes from someone in Europe - I don't > believe our database currently contains these, as they were purged from the > BSD package from which ours is derived but I would be prepared to be very > wrong here. > > The point was made that if the database did contain Nazi quotes / a swastika > it might make it illegal to host the content on mirrors in at least Germany > or Austria. ❯ apt source fortunes-off Leser pakkelister ... Ferdig MERK: «fortunes-off»-pakker blir vedlikeholdt i versjonskontrollsystemet «Git» på: git://anonscm.debian.org/collab-maint/fortune-mod.git Brug venligst: git clone git://anonscm.debian.org/collab-maint/fortune-mod.git for at hente de seneste (muligvis ikke udgivet) opdateringer til pakken. Trenger å skaffe 2 124 kB fra kildekodearkivet. Hent:1 http://deb.debian.org/debian sid/main fortune-mod 1:1.99.1-7.1 (dsc) [2 071 B] Hent:2 http://deb.debian.org/debian sid/main fortune-mod 1:1.99.1-7.1 (tar) [1 812 kB] Hent:3 http://deb.debian.org/debian sid/main fortune-mod 1:1.99.1-7.1 (diff) [309 kB] Hentet 2 124 kB på 0s (4 918 kB/s) dpkg-source: info: extraherar fortune-mod i fortune-mod-1.99.1 dpkg-source: info: packar upp fortune-mod_1.99.1.orig.tar.gz dpkg-source: info: packar upp fortune-mod_1.99.1-7.1.debian.tar.bz2 dpkg-source: info: använder patchlista från debian/patches/series dpkg-source: info: tillämpar datfiles.diff dpkg-source: info: tillämpar readme.diff dpkg-source: info: tillämpar todo.diff dpkg-source: info: tillämpar man.diff dpkg-source: info: tillämpar fortune.c.diff dpkg-source: info: tillämpar fortune-clean.py.diff dpkg-source: info: tillämpar shortcut_cookie_lists_build_system.diff dpkg-source: info: tillämpar typo_in_manpage.diff dpkg-source: info: tillämpar respect_buildflags.diff dpkg-source: info: tillämpar gcc_warnings.diff dpkg-source: info: tillämpar fortunes.steve_jobs.diff dpkg-source: info: tillämpar quotes_not_properly_divided.diff dpkg-source: info: tillämpar dennis-ritchie.diff dpkg-source: info: tillämpar search_LOCFORTDIR_even_if_LANG_not_set.diff dpkg-source: info: tillämpar remove_backspaces.diff dpkg-source: info: tillämpar rochefoucauld.diff dpkg-source: info: tillämpar irish_ballad.diff dpkg-source: info: tillämpar corbet.diff dpkg-source: info: tillämpar typo.diff dpkg-source: info: tillämpar manpage_bugs.diff dpkg-source: info: tillämpar songs-poems.diff dpkg-source: info: tillämpar mark_twain.diff dpkg-source: info: tillämpar autocad.diff dpkg-source: info: tillämpar lawyers.diff dpkg-source: info: tillämpar politics.diff dpkg-source: info: tillämpar off-wrong-man.diff ❯ grep -ri "Mein Kampf" fortune-mod-1.99.1/datfiles | wc -l 52 The question is not whether hosting is illegal (I don't think it is). The question is whether we promote Nazi ideology or not. And the answer is clearly "No", and that is a fact, not sumething that is up for discussion. -nik signature.asc Description: PGP signature
Re: DNS records for the Debian Academy
Dashamir, > I'm afraid it is not so (look at the other message). > But I am not going to engage in his discourse. I'm afraid you still refuse to learn about proceedings in the Debian project. Also, you seem to repeatedly read "I do not want to hand over full control to you" as "I do not want to help you". I offered to reestablish the Moodle hosting for your project. If you think this is not helping you, then this is something you have to cope with. My only condition was that you get another DD involved. Sadly, by now, I have well-founded reasons to believe that you have driven all DDs in the Academy team away with your attitude. And yet, I am still willing to support your efforts, if you show some will to cooperate instead of insisting on taking over full power right from the start. -nik
Re: DNS records for the Debian Academy
Dashamir, > We have had discussions on the mailing list, we have had several meetings, > where have you been? What kind of ping do you need? > > You know how the first iteration ended, don't you? We are trying to do > something better this time. Maybe the "second iteration" is going to have the > same end and the first one, I don't know. But we are giving it a try anyway. I consider your way of interacting with other community members as not helpful. And I ask you to reconsider it, and ask yourself whether you have the skills to drive a community project in Debian forward or not. I conclude that from my observations from Debian Edu as well. Our first encounter was you grabbing tasks in Debian Edu which others had stood up for, without properly interacting with them. I see the same pattern happening here, and it is the reason why I have refrained from participating in your efforts to date. The first iteration Endes because no content was produced, because the Academy team did not find the time. It did not end due to any technical issues or issues with the hosting. I see no reason why handing over hosting or DNS to you should change anything about the availability of team members producing content. Lastly, I do not need to attend any regular meetings in order to manage a VPS and a Moodle installation. I do not have time to get involved with Academy more closely than operating the necessary platforms, but I still can do that. What I will not do is point a Debian DNS record to a machine managed by you, because I had no chance to build enough trust in your work to date. The kind of ping I need is a mail with something like "Nik, can Teckids please provide a Moodle VPS for Academy again?". That does not require attending any meetings. Yet, please make sure that another DD from the Academy team steps up to get root access to that machine. -nik
Re: DNS records for the Debian Academy
Hi, > Thanks for your suggestion. With all due respect, please allow me to decline > it. I am giving it a try anyway. I know you are aware that the hosting of Moodle and such for Debian Academy is actually a solved issue. If Debian Academy wants to restart their efforts and wants a machine with Moodle and academy.debian.net pointing to it, all that is needed is a friendly ping with that information to the DD who has been managing it during the first iteration (which is me). -nik
Re: DNS records for the Debian Academy
Hi, > Exactly. Besides DebianEdu, I am also trying to help Debian Academy, as much > as I can. > I consider my motivations and goals a private thing, so I'd prefer to not > share them with the wider public, if possible If your motivations are private, then I'd suggest you not use Debian's community infrastructure and not request privileges within the community for it. -nik
Re: DNS records for the Debian Academy
Hi, > But we still need some help for registering the domain > academy.debian.net[http://academy.debian.net], since this can be done only by > a DD. The details of how it can be done are described here: > https://wiki.debian.org/DebianDotNet > > More information about the DNS records that need to be registered is given in > this message: https://lists.debian.org/debian-academy/2022/09/msg00048.html > > Is there any DD that can help us? > Alternatively, how can I get DD permissions, so that I can try it myself? What is your relation to the Debian project? I have not seen any contributions so far (besides from trying out Debian Edu), so I wonder what your motivations and goals are. Also, Debian Academy very much used to be run by project members (DDs). Where have they gone? Who is Debian Academy now? -nik
Re: Banning Norbert Preining from planet.d.o
> There's no link between Jonathan being the current DPL ("has abused his
> powers")
I did not say "his powers as DPL".
-nik
Re: Banning Norbert Preining from planet.d.o
Hi, > ... and if there was any doubt I could possibly vote you above NOTA, here it > goes away. Continuing harassment of Norbert is not appropriate. > > The toxic environment remaining here must stop. While I agree that Jonathan has abused his powers and should not have removed anyone from planet on his own, your argumentation is toxic in itself. You are justifying a bully. Norbert Preining is a bully, and has to be stopped. Justifying his actions and involve in victim blaming means you are a bully as well. You can perfectly promote democracy and demote abuse of powers of single persons **and** refrain from accepting bullies at the same time. -nik
Re: New DEP: Usage of SDPX in debian/copyright
Hi, > No one uses our RFC-2822-style thing except us, and no one has tools for it Well, then they should just apt install them. I failed to understand SPDX until today (with the exception of the license specifiers), which is mostly due to the quadrillion different formats SPDX data can come in. I am totally for aligning the License: field with SPDX licence specifications, but that's it. For everything else, SPDX is a PITA. -nik
Re: Debian and GitLab Open Source Partnership
Hi, > Debian and GitLab have been in discussion regarding an Open Source > Partnership toward which we will jointly produce mutual promotions, > shared stories, and announcements using both organizations press and/or > publicity channels. > > There are several segments for this upcoming and future endeavor which > include a few requests from them on: How Debian uses GitLab for a case > study, some highlighting and promotion from us regarding their upcoming > GitLab Commit 2021 Conference, mutual support with media (peertube for > example), and a hand in hand expansion of both our press/publicity > networks to promote each others work where applicable. Without the intention to criticise the idea in general, has the responsible team considered any conflicts between GitLab's practices how they do open core rather than free software, and the DFSG? Are they compatible? Will this partnership help improving the use and support of GitLab in Debian, i.e. will GitLab start supporting the GitLab packaging efforts in Debian, and help the Salsa team? Cheers, Nik
Re: My first spam on lastname-firstn...@debian.org address.
Hi, > in my case, login == lastname). That's the twist here – it seems the debian.org mail server accepts - as a local extension character (in addition to +). At least, I successfully received mail at natureshadow-foobang@d.o _-nik_
Re: General Resolution: Richard Stallman's readmission to the FSF board
Hi, > The problem is that for good reason, we no longer trust the FSF under > its current governance to do that. What you are affectively asking > people to do is to pursue justice in regard to things rms did in a forum > where rms has much more power than they do and where rms (and the voting > members of the fsf) have demonstrated they will use that power in non > equitible ways. > > Given how rms returned to the board, how can you possibly think those > people will get a fair hearing. Obviously, such a committee would have to be instated in a transparent way and in close cooperation with people and organisations not involved with rms otherwise. I do think that this is possible by both having the current FSF board start such action, but not take control of it. An investigation committee consisting of the FSF board, or solely people nominated by them, of course has no value. -nik signature.asc Description: PGP signature
Re: General Resolution: Richard Stallman's readmission to the FSF board
Hi, > A General Resolution has been started about Richard Stallman's > readmission to the FSF board. > > It currently has 1 available options, but other proposals have been suggested. I explicitly do NOT support this GR. My opinion, as laid out at https://github.com/rms-open-letter/rms-open-letter.github.io/issues/2285: 8><-- With the FSFE freezing its collaboration with the FSF, projects signing open letters to effectively disassemble the FSF and the GNU project altogether, it seems we are officially at war. With all due respect to everyone who has been offended by Richard Stallman, feels oppressed by him, or is negatively affected by his views — every single such person has to be heard, their fears and sorrows been taken into account, and appropriate action been taken. As such, I am in full support of requiring the FSF board to instate an investigation committee, take letters from anyone affected, and hear these cases (including rms' position). What I do not support is forcing the disintegration of the FOSS community, even less in such crucial times. The COVID pandemic forces evryone to digitise the hell out of them and their organisations, and every action that weakens the FOSS movement in this ciritical process certainly does more harm to the ecosystem than a single person on any FOSS body's board ever could. Thus, I consider those responsible for this, in my opinion, thoughtless action harmful to the FOSS ecosystem. As already said, I am in full support of an investigation committee, and would immediately sign an open letter requesting the FSF to instate one (including a helpful list of requirements for this committee). Thanks for listening! P.S.: On a side note, hosting this thing on GitHub, which explicitly discriminates against parts of the community and is itself harmful to the FOSS ecosystem as a whole, is at least a bit weird. --><8 As such, I want to make the following amendment: 8><-- Choice 2 The Debian Project does not co-sign the statement regarding Richard Stallman's readmission to the FSF board seen at https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md In its role as an important body in the free software world, the Project has made its members aware of the situation, and respects the opinion of all of its members. In doing so, every member is free to sign the statement, or to not do so. The Debian Project make an official statement, along the lines of: * We have learnt about rms being readmitted to the FSF board * We are aware of critical voices regarding the person known as rms, and we take every single report very serously * Everyone who is affected by any action, opinion or statement of rms can ask the Debian Anti Harassment team for support, and the Anti Harassment team will suppor tthem in communicating with the FSF and ensure their concerns are addresses * The Debian Project supports the instatement of an investigation committee regarding all accusations against rms and asks the FSF board to take such action, in close cooperation with other organisations and in full transparency --><8 Kind regards, Nik signature.asc Description: PGP signature
Re: Package request
Hi Justin, thanks for your request. > Hello guys, I am inquiring if you make a package which would like > onenote for microsoft. Do you have a interactive package that would be > used just like onenote or similar? Also do you make a package like a > virtual machine or similar where you can instal windows in and run > windows through debian platform? This mailing list is for non-technical discussions about the Debian project itself, not for user requests. Please send your request to debian-u...@lists.debian.org, where other users and also Debian project members provide help. While at it, may I ask you to choose a more inclusive greeting (unless there is a reason you only accept replies from male supporters ☺). Some ideas include "Hi people", "hi folks", "hi friends", "Hi fellow users", and some others. Thanks and see you there, Nik
Re: Repeating: Only the Automatic Approvals of BSP Reimbursements are on Hold; You scan still Ask
> Asking for pre approval als means you don't book tickets and arrange travel > before knowing if you are going to be able to claim back > This to me is the best cause of action for any proposed expenditure Plus, in my experience, for me as a participant it is not too much of a hassle. In most cases, I literally got a pre-approval within minutes (don't abuse this quote to demand such a quick reaction from Sam or any future DPL!) -nik
Debian Edu sprint at MiniDebConf Hamburg, 5th to 9th June 2019
Dear interested contributors, from 5th to 9th June, there will be another MiniDebConf in Hamburg, and the Debian Edu team will again hold a sprint during that event. For those who do not know about Debian Edu yet: Debian Edu is a pure blend, developing a full-featured school network solution, including server operation, desktop for students and teachers, and much more. The product is also known by its second name Skolelinux. A tentative agenda is posted on the wiki at https://wiki.debian.org/Sprints/2019/DebianEdu . We welcome not only existing team members, but everyone who is interested in helping with a future-proof, good product for open education, and all that as a Debian pure blend. Exciting things like integration of cloud and other apps, mobile device management, and better support for interactive whiteboards are on the road ahead. If you are interested in attending, please sign up on the wiki page, or by sending a short e-mail to me. Looking forward to seeing you! P.S.: If you need support with accomodation or travel costs, and are not attending MiniDebConf besides this sprint, please get in touch. signature.asc Description: PGP signature
Re: Censorship in Debian
>But we, as a project, need to ensure that there is more transparency >moving forward. And I think it would be wise to review the way that >DAM and AH operate. We need to ensure they stick to protocol, and >are held accountable for the use of their powers. This! -nik
Report on Debian Edu sprint at MiniDebcon Hamburg, May 2018
Hi all, a bit late, but here's the report for the Debian Edu sprint at MiniDebconf Hamburg: The sprint was more or less extended over the entire five days of MiniDebconf, with everyone interested working on some tasks in Debian Edu, and regular, half-daily meetings. Holger Levsen, who also organised large parts of the MiniDebconf itself, mainly worked on the preparation and coordiantion of the Debian Edu core packages migration to Salsa, which reqired some thought about what dependent systems and configurations would have to be changed, and created a list of tasks that was worked on during and after the sprint to finish the migration. Wolfgang Schweer worked on the Debain Edu isntallation profiles and decoupling specific aspects of the installation, so installation of minimal systems and specialised systems (e.g. as a router, separate backup server, etc.) becomes easier. He also worked on Debian Edu tests during image building and autopkgtests. Together with Mike Gabriel, he introduced and tested teh desktop-autoloader system that will ensure fast loading times of PXE clients in classrooms. Besides that, NFS moutns in the preconfigured Debian Edu network were made more secure by extending the Kerberos setup to them. Last, but not least, efforts were doen together with Phil to get the Debian Edu installation iamges built on official infrastrucutre and using official CD building procedure. All that, togheter with some other aspects, was also updated in the Debian Edu manual. Mike Garbeil was involved in talking to new and old developers and maintainers, and ensuring the community got to know each other better. He did some special work for schools using Debian Edu in Schleswig-Holstein. Mike and Nik gave a talks on the state of Debian Edu, presenting the history, current projects, goals and ideas, and the state of the community in Germany. Another outcome of the team meetings during the sprint was that we will focus on involving the German community a bit better. We will plan a meeting where we will work on the non-technical aspects of Debain Edu (and free software in education), in order to find out how we can place Debian Edu in more German schools. Thanks to everyoen who attended the sprint. Cheers, Nik signature.asc Description: PGP signature
Debian Edu sprint at MiniDebConf 2018 in Hamburg
Dear Debian Edu contributors, as discussed on IRC, we will have a sprint at the MiniDebConf in Hamburg [0] on 17th and 18th of May (mainly on 18th, but at least tg@ and I will start on 17th, and hope some others to join). You can find the provisional agenda and list of participants on the Wiki page[1]. For those on the non-edu lists, a quick reminder what Debian Edu is: Debian Edu is a pure blend tailored to the needs of educational networks. Debian Edu, or Skolelinux, provides preconfigured profiles for school network servers and educational desktops, together with a fully configured network with all necessary services. One of the main aspects of the sprint is coordination between developers and the German support community, in order to make Debian Edu fit for the German educational market, and to solve some issues early i nthe buster development cycle. If you attend the MiniDebConf and are interested in Debian for education, you are welcome to join us. Please add yourself to the Wiki or send an e-mail so we can plan with you. If you did not consider coming to MiniDebConf yet, you maybe should ;)… We are looking forward to the sprint! Cheers, Nik [0]: https://wiki.debian.org/DebianEvents/de/2018/MiniDebConfHamburg [1]: https://wiki.debian.org/Sprints/2018/Edu -- Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter) Teckids e.V. - Erkunden, Entdecken, Erfinden. https://www.teckids.org/ signature.asc Description: PGP signature
Fwd: User Experience Survey on Bug Tracking Tools | Debain Team
Hi there, Sai, the author of the Bug Tracking Tools survey that was sent here a few weeks ago and that, primarily due to my feedback, caused a lot of heated discussion, jsut came back to me with a plain text form, asking me to forward it to the list. (Sai, don't fear to do that yourself ;)! We normally do not bite.) I thought I'd take the chance to express my apologies for having conveyed my opinion in a less peaceful than appropriate manner. Thank you Sai for implementing the feedback although it carried a lot of criticism! Cheers, Nik Forwarded Message Subject: User Experience Survey on Bug Tracking Tools | Debain Team Date: Tue, 23 Jun 2015 01:44:58 +0530 (IST) From: Sai Anirudh sai.anir...@research.iiit.ac.in To: Dominik George n...@naturalnet.de CC: sai anirudh sai.anir...@research.iiit.ac.in Dear Sir, Good Day ! Thank your for you valuable feedback on formulating the survey for open source community. It was really helpful. We have revised our survey on bug tracking tools in a Email free text format. Will you be able to share the below survey to your team to capture their user experience ? This will really help us to understand the personal experiences of bug reporters, bug fixers and testers. Survey on Bug tracking tools: == Intent: As part of our research, We students of IIIT Hyderabad (https://iiit.ac.in) would like to study on user experience while using Bug tracking tools in Open source software community. We request to please reply us back to my email - sai.anir...@research.iiit.ac.in with your feedback. Please go through below queries and share your observations. 1. How many years of work experience you have in area of Software Maintenance (As a Bug reporter/Bug fixer/ QA Manager or developer )? Less than 1 years Between 1 and 5 years More than 5 years 2. Which Bug tracking tool is used for your Open Source Project ? - Text Field response 3. As a Software maintenance professional (bug reporter, bug fixer, QA Engineer or developer) How important the bug tracking tool is for your Open source project ? High (We cannot work with out it) Moderate (We just need it) Partially (Not so important) Low (We don't use any) 4. As a Software maintenance professional (bug reporter, bug fixer, QA Engineer or developer) Does your bug tracking tool meet all your requirements ? Yes - 100% (it covers all our requirements) Moderate - 75% - 100% (it covers almost all requirements) Partially - 50% - 75% (it partially covers our requirements) No - below 50% (it don't, but we got habituated to it) Comments:(If any) 5. As a bug reporter, Does your bug tracking tool help you share all required details without any changes made to existing tool (with no additional API) ? Yes - 100% (all options are readily available) Moderate - 75% - 100% (We use APIs for few options) Partially - 50% - 75% (We use APIs for almost all options) No - below 50% (We completely depend on external API) Comments:(If any) 6. As a Bug fixer, Does your bug report explain everything you need to fix the issue ? Yes - 100% (Bug report has all required features) Moderate - 75% - 100% (We customized few options on our bug report) Partially - 50% - 75% (We customized almost all options on our bug report) No - below 50% (We use completely a custom bug report) Comments:(If any) 7. Does your bug tracking tool provide all desired/standard features (Customizable Bug template/Reporting/Trend Analysis/Archive etc.) ? Yes - 100% (meets all desired features) Moderate - 75% - 100% (meets all almost all features) Partially - 50% - 75% (meets only few features, we depend on APIs for desired features) No - below 50%(Very few features, we completely depend on APIs for desired features) Comments:(If any) 8. What are the features which are desirable but not provided by your bug tracking tool ? Comments: Appreciate your assistance in this regard. Regards, Sai Anirudh Karre Email: sai.anir...@research.iiit.ac.in University: IIIT Hyderabad, India (https://iiit.ac.in) signature.asc Description: OpenPGP digital signature
Re: What it means to be Debian
Hi, I find it difficult to express my disagreement with the your views, and your attitude, with the respect that is due to a fellow contributor. But I will try. I looked, but somehow failed to see how the peer in question is a contributor. All there is is a demand for *our* contribution in *their* project. Taking that into account, I again explain that they proved, in the very same mail, that they *do* have access to reasonable e-mail infrastructure, but still decided they wanted to look as close to spam as they could get. A simple plain text form would have done the trick as far as that Google Docs thing is concerned. Its results would have been easily parsable by someone dealing in software development, as the posters obviously do. So, in conclusion, both Google Mail and Google Docs would have been avoidable, and were only chosen in order to not have to put any own effort into getting hold of the results of *our* contributions - which is a sad thing. -nik -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/4a949b67-5861-46cb-b7f8-ae4e0cd4e...@naturalnet.de
Re: What it means to be Debian
Hi, This issue is important enough to me that I'd like to take a moment to share mine. I'm not trying to pursuade you. I really appreciate how you presented your position; you didn't try to say I was wrong, and you were honest and open even when there is disagreement. I am not judging you or trying to say you are wrong. We disagree quite strongly, but at least today, there's room for that. Thank you! If you succeed in making this sort of belief in free software a condition of being part of Debian, you will drive me and probably others away. I suspect that personally I meet your requirements. However I wouldn't want to be part of such a closed community even if it would have me. I'd be sad if that happens, but I'd honor the change in the community. my reading of the current Debian is that I am welcome and that while a lot of us do value free software for itself, we are open to anyone upholding the DFSG and social contract. I strongly support that. I also do *not* think that everyone who uses non-free services or the like should leave Debian or is neitrely bad for the community. Mostly, I *personally* do not find those people authentic enough to uphold any such community standard. It's somewhat like donating to a species conservation organisation, taking the money from a purse made of crocodile skin. It's quite impossible to take it seriously. -nik signature.asc Description: OpenPGP digital signature
Re: Survey on Bug Tracking Tools
Hi,o On 16.06.2015 05:00, Sam Hartman wrote: Dominik == Dominik George n...@naturalnet.de writes: Dominik On 08.06.2015 20:46, Florian Weimer wrote: Google services are quite popular among the FLOSS crowd at large. You might not see many Gmail posters on Debian mailing lists, but this is increasingly an anomaly. Dominik Which is, at best, a serious illness. I'm really frustrated reading this. I'd like to share my frustration in hopes of seeking understanding and confirmation that we share the core value of working with a diverse set of contributors. Sure. I hope Debian is a community that can respect a diverse set of needs and beliefs. Yes and no. AFAIAC, and in reference to the term „serious illness“ I used, I think of it in the following way: a) NEEDS If our contributors NEED features that only Google, or the like, can provide, then the serious illness lies in that we, the FOSS community, obvioulsy failed to provide something comparable or even better. b) BELIEF = If any Debian contributor BELIEVES that the use of Google, and the like, is a good thing, then the illness lies in the divergence between their contribution and their values, and in that case, I honestly do NOT respect that and consider it harmful. I really also see a strong imbalance between various parts of the project. On the one hand, there is a non-free section that holds non-free software, ready to be installed by users at will. Then, there is you (and probably others) argumenting in favour of placing everyday communication in the hands of companies which are proven to not respect freedom. But on the other hand, we do care a lot about CDM/EME being stripped out of the Firefox code just because some people do not like DRM (neither do I, but if it is ok to route our *global* communication through Google, why isn't it ok to route my *local* streaming through CDM code, and not even leaving that decision up to me? Really - please fight for freedom on all ends, or at least align your views about accepting non-freedom on all ends. -nik signature.asc Description: OpenPGP digital signature
Re: Survey on Bug Tracking Tools
On 08.06.2015 20:46, Florian Weimer wrote: Google services are quite popular among the FLOSS crowd at large. You might not see many Gmail posters on Debian mailing lists, but this is increasingly an anomaly. Which is, at best, a serious illness. -nik signature.asc Description: OpenPGP digital signature
Re: Survey on Bug Tracking Tools
Hi, On 08.06.2015 10:26, sai11101...@gmail.com wrote: We the students of IIIT Hyderabad (https://iiit.ac.in https://www.google.com/url?q=https%3A%2F%2Fiiit.ac.insa=Dsntz=1usg=AFQjCNFMgVcVzfdLIP6a-9Vqbq2lVGNXHA), as part of our research on improving the features provided by Bug Tracking tools, we are reaching out to Open Source Software (OSS) Development Community to capture your feedback on your experiences on using bug tracking tools as part of your OSS product development. Thanks for your efforts. However, I (for one) am not so comfortable with your proceedings. 1. Your e-mail doesn't even carry a real name (and originates at Google Mail, in combination making it look a lot like spam). Why not send it from a university address with a readable name, making it look like it was send by an academic? 2. The data has to be entered in Google Docs / Google Forms. Excuse me, but weren't you saying you are reaching out to Free Software projects? I do not see why, as a Free Software contributor, I should act upon a mail that looks as close to simple spam as it can get and asks me to enter stuff into an insecure, untrusted and non-free application. Sorry, Nik signature.asc Description: OpenPGP digital signature
Re: @debian.org mail adress
Hi, On 18. Mai 2014 23:56:29 MESZ, Kolega Wikipedia kolega2...@gmail.com wrote: How to get @debian.org email addres? First, get a name. Second, become a Debian Developer! Cheers, Nik -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f9e91076-03a1-4b81-918a-651661094...@email.android.com
Re: working with FSF on Debian Free-ness assessment
Hi, Free Software is meaningless without having free users, users that aren't able to take control of their software are not free users, they're slaves to the creators of the software. That's what I meant. If the FSF (or Debian) says: It is absolutely unacceptable to run non-free software on this system! then the users are slaves of the creators of Debian. Of course, all users SHOULD be using entirely free software, but they MUST still be able to make an active decision against it. -nik -- Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: working with FSF on Debian Free-ness assessment
Correct. Unfortunately I haven't heard much else either. Discussions went on on the fsf-collab-discuss list on alioth, but the state of the art is still that we're waiting for the FSF to refine current freeness assessment into more actionable items. Just out of curiosity: What's their definition of freedom anyway? Forcing the user to not use non-free software takes away their freedom, but probably the FSF does not get that, or they wouldn't be pushing the GPL so badly. But is there any real reason behind that, apart from the religious ones? -nik P.S.: I would prefer non-free and contrib being completely removed as well, but my question is why that has to be forced on others. -- Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: working with FSF on Debian Free-ness assessment
Just out of curiosity: What's their definition of freedom anyway? You don't know what their definition of freedom is, but continue to assess their religious views? This doesn't look very useful to me. I know very well what their definition of freedom is. My question challenges the valdity of their definition. -nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * mirabilos That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Das geht ja gut los
Hi, will mir das netinst ISO laden und was bekomme ich ? Server nicht gefunden ! So kommt keiner vom Micromist System los. 1. this is an English mailing list 2. this is not a support mailing list 3. how did you try to download the image? If you used the link on the.start page, then yes, it is broken with a 404 Not Found, but not with the message you mentioned. Thanks for the report, but please try to.be more accurate and constructive next time, both towards us *and* Microsoft! Cheers, Nik -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f614a03e-1f82-4a70-ba59-e1343b042...@email.android.com
