Re: Idea: frontend tool for more efficient license reviewing based on tree-structured IR
On Friday, 27 December 2019 02:56:07 CET Mo Zhou wrote: > https://wiki.debian.org/CopyrightReviewTools > > I'm unfamiliar with most of them. I'm only describing the two I'm familiar > with. Both licensecheck (Jonas) and debmake (Osamu) do template/regex > matching. I'd suggest you to look at 'cme' as this tool is closer to what you want to achieve. For details, please see https://github.com/dod38fr/config-model/wiki/ Updating-debian-copyright-file-with-cme > * Tree structure is always missing. after importing a new upstream release > with significant directory layout change, it will be inconvenient to > locate the parts of debian/copyright should be updated. Things will become > more complex when new licenses/copyrights emerged. This use case is handled by 'cme update dpkg-copyright' which merges information from current debian/copyright with the information provided by the new release. > * licensecheck dumps garbage when it encounters a binary file, e.g. PNG > image. This is not a BUG, as ftp-masters indeed checks the possible > metadata in a binary file to make sure whether there is extra > copyright/license info. But this is something needs to be improved... As cme relies of licensecheck, this is also a sore point which can be allieciated by tuning debian/fill.copyright.blanks.yml (see URL above for details) > The core of my idea is a tree-structured intermediate representation (IR) > for the "license reviewing tree". The IR is basically a directory tree with > annotations on the file nodes. The IR can be stored as a, say, JSON file. This IR tree is constructed by 'cme' when processing licensecheck information, but is not saved after debian/copyright is updated. > To build such an tree-shaped IR, we need a couple of "backend" tools for > checking the copyright & license info for a SINGLE file. Such "backend" > includes but not limited to: > > * `licensecheck`. Given a file FILE, `licensecheck FILE` produces the > license name. > * `grep` or `ripgrep`. For example, `rg -i copyright FILE` always works > well. * "neighbor". For example, given a source file "F/I/L/E" without any > copyright & license info, looking for F/I/L/LICENSE, F/I/LICENSE, ..., etc > like git does for the ".git" directory will help. cme also infers "global" license information from README, LICENSE files to use as default values when no specific license information is found in files. > The formated+filtered output of any combination of these backends can be > attached to the corresponding IR. > > In contrast, a "frontend" tool is also needed for dealing with such IR > in a higher level. My imagined "frontend" tool is a `ranger`-like file > browser with specific designs. cme provides a frontend to debian/copyright structure (shown as a tree in this frontend) with 'cme edit dpkg-copyright' See https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme#maintaining-debian-copyright-file > * the user can choose what backend(s) to use. If none is chosen, the > frontend tool falls back into a general file browser with a preview panel. cme only uses licensecheck backend. I did not see a need to try another tool to extract license information from files. > How to proceed > -- > > * a group of interested contributors. If needed, I'm willing to tweak cme (*) so you can re-use cme (or parts thereof) for your project. All the best (*) Actually, the code that handles copyright information is in libconfig- model-dpkg-perl, which is a cme plugin to handle dpkg files: https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl
Re: Vital fix to console-common stuck in testing for three months
Den mån 16 dec. 2019 kl 02:40 skrev Henrique de Moraes Holschuh < h...@debian.org>: > On Mon, 16 Dec 2019, Oskar Berggren wrote: > > This was reported in August 2019 as a grave bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935096 > > > > It was fixed early September in 0.7.91 and migrated to testing > 2019-09-13: > > https://tracker.debian.org/pkg/console-common > > > > Sadly, this fix has not yet made it into stable. Is something holding > this > > up, or has it just been forgotten? > > Fixes only make it to -stable when the maintainer (or another DD) > actually acts on it, prepares a stable upload (s-p-u), and talks to the > stable release manager team to get it approved. > > Alastair, are you planning a s-p-u with a fix for 935096? > > Alastair, any feedback on this?
Re: Vital fix to console-common stuck in testing for three months
Speaking as an experienced developer reasonably familiar with our processes, but *not* as the DPL. At this point if there has been no response from the maintainer, I think it would be reasonable for an interested party to propose an update to the release team noting that the maintainer is silent. They may wait a week or two for another round of comments (or lack) from the maintainer. My comments are based on reading the d-devel threads and not on any additional analysis; if there are facts not described on debian-devel they may affect my conclusions. --Sam
Bug#948282: ITP: djangorestframework-api-key -- API key permissions for Django REST Framework
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: djangorestframework-api-key Version : 1.4.1 Upstream Author : Florimond Manca * URL : https://florimondmanca.github.io/djangorestframework-api- key/ * License : MIT Programming Lang: Python Description : API key permissions for Django REST Framework Django REST Framework API Key is a powerful library for allowing server-side clients to safely use your API. These clients are typically third-party backends and services (i.e. machines) which do not have a user account but still need to interact with your API in a secure way. I intend to package this module within the Python team.
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
On Wed, 01 Jan 2020, Otto Kekäläinen wrote: > Hello! > > ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti: > > On Mon, 30 Dec 2019, Bernd Zeimetz wrote: > > > Also, if resources are an issue: I've offered several times to see if I > > > can get some k8s resources for gitlab runners, but never got a reply. > > > Not even a no. > > It is not a problem on the runner side. > > > > And as said, we are working on the other problems until we can improve > > something in that part. > > If it is not a problem on the runner side and you don't need more > runner resources, what is the reason the runner is capped at 1h? > MariaDB is a huge beast and building it and running all tests take > 1,5h for completely valid reasons (also note we have ccache on > Salsa-CI so re-builds are much faster). We updated the timeout to three hours. However, if that leads to problems on salsa side we will have to set it back. So please ensure not to create too much load / jobs that use that extended limit. For everything else: we are working on it. Alex
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
> "Alexander" == Alexander Wirt writes: Alexander> For everything else: we are working on it. I just want to confirm that part of the things that you are working on is documenting the issues. At a number of points you've talked about how people are misunderstanding the issues or are thinking it's simply more CPU etc. That's all doubtless true. But part of being in a community is communicating with that community. People would almost certainly be more understanding if they had more information. Yes, that sort of communication does involve time, and yes that time could be spent fixing things. There comes a point though where the communication becomes at least as important as the fix. I think I've heard several requests for more information here, and I just want to confirm that too is in your queue. --Sam
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
On Mon, 06 Jan 2020, Sam Hartman wrote: > > "Alexander" == Alexander Wirt writes: > > Alexander> For everything else: we are working on it. > > I just want to confirm that part of the things that you are working on > is documenting the issues. At a number of points you've talked about > how people are misunderstanding the issues or are thinking it's simply > more CPU etc. > > That's all doubtless true. > But part of being in a community is communicating with that community. > People would almost certainly be more understanding if they had more > information. just for the record, I am doing all of this in my spare time and I prefer to decide on my own what is in my queue and what the priority is. And yes, I do prefer to fix things instead of documenting what needs to get fixed. And if everyone would behave sane instead of st* flame wars, insulting each other and so on (it was a listmaster month to forget) my motivation to work with that specific community would be a lot better. And for everyones sake: when announcing CI support we told everyone that the ressources are limited and everyone should play nice with the CI. As often, other people decided to make the CI and the runners a quasi standard, adding it to their workflows and so on. Now everyone is surprised if things are as we always told everybody. What a surprise. Thanks for listening. Alex signature.asc Description: PGP signature
Re: Next attempt to add Blends to Debian installer
Hey Andreas! On Wed, Dec 18, 2019 at 08:23:39AM +0100, Andreas Tille wrote: > >the first alpha of the installer of Debian 11 is out. As we talked at >DebConf about better Blends support: Is there anything we can test >regarding tasksel? Not yet, I'm afraid. A little too swamped so far, but you're near the top of my TODO list. I'm hoping to get some time for development on this in the next couple of months. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
Hi formorer, > On 28.12.19 18:16, Alexander Wirt wrote: >> On Thu, 26 Dec 2019, Otto Kekäläinen wrote: >> I am sure there are many ways to help the team and it is not just >> about Salsa/Gitlab admin stuff, but also about creating structure in >> the team, triaging issues, spreading best practices for users and >> helping the most advanced users to grow into admins of Salsa etc. >> Right now we don't even have any kind of salsa-related discussion >> list on lists.debian.org. Thus I wanted to raise discussion on >> debian-devel. In my opinion Salsa is becoming a very central piece of >> the Debian infrastructure and it should have more attention on >> debian-devel and from the project leader. > We are working on it and after my holidays are over I will plan > another sprint for improving salsa. >From your replies to emails in this thread I was wondering: do you mean that the Salsa team does not need, or does not want, help? Or does not need, or want, help outside of a sprint? -- ulrike
Re: Vital fix to console-common stuck in testing for three months
Hi Apologies I have never done a stable update, and am not sure I have permissions. I've submitted the bug request with debdiff to release.debian.org for FTP master go-ahead in the next upload. Best regards Alastair On 16/12/2019 01:17, Oskar Berggren wrote: Hi, Buster has 0.7.90 of console-common, which unfortunately has a bug so that the install-keymap binary was accidentally excluded from the package. This was reported in August 2019 as a grave bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935096 It was fixed early September in 0.7.91 and migrated to testing 2019-09-13: https://tracker.debian.org/pkg/console-common Sadly, this fix has not yet made it into stable. Is something holding this up, or has it just been forgotten? I'm working to update a custom "edition" based on something like old-old-old-stable to Buster and am now stuck in this because I cannot get the boot keymap I want. Kind regards, Oskar -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Re: Condorcet Internet Voting Service
On Sun, Jan 05, 2020 at 06:01:58PM -0800, Felix Lechner wrote: > No one should hold a grievance for a year. The survey's author is > welcome to send me an email with details. I would be happy to take up > the issue with relevant parts of Debian without revealing the sender's > identity. If you did so, then you would be allowing yourself to be manipulated into being a tool of a harasser. Debian does not expel developers often, or without cause. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
On Mon, 06 Jan 2020, Ulrike Uhlig wrote: > Hi formorer, > > > On 28.12.19 18:16, Alexander Wirt wrote: > >> On Thu, 26 Dec 2019, Otto Kekäläinen wrote: > >> I am sure there are many ways to help the team and it is not just > >> about Salsa/Gitlab admin stuff, but also about creating structure in > >> the team, triaging issues, spreading best practices for users and > >> helping the most advanced users to grow into admins of Salsa etc. > >> Right now we don't even have any kind of salsa-related discussion > >> list on lists.debian.org. Thus I wanted to raise discussion on > >> debian-devel. In my opinion Salsa is becoming a very central piece of > >> the Debian infrastructure and it should have more attention on > >> debian-devel and from the project leader. > > > We are working on it and after my holidays are over I will plan > > another sprint for improving salsa. > > >From your replies to emails in this thread I was wondering: do you mean > that the Salsa team does not need, or does not want, help? Or does not > need, or want, help outside of a sprint? That basically means: yes we probably need help. But it also means that getting help should be done in a coordinated way, like introducing one or two team members during a sprint. Getting someone new involved always means overhead and should happen when there is time for such overhead. In my experience sprints are ideal for it. I also talked to some people about getting them involved in salsa, but there will also be a call for help. I / we plan to add at least one global admin and maybe one or two assistants that help with "user" support. We just need some time to plan and coordinate those things (around christmas is really a bad timing for such discussions) Alex
Bug#948303: ITP: aionotify -- Simple, asyncio-based inotify library for Python
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: aionotify Version : 0.2.0 Upstream Author : The aionotify project * URL : https://github.com/rbarrois/aionotify * License : BSD-2-Clause Programming Lang: Python Description : Simple, asyncio-based inotify library for Python Asyncio library to create watchers on filesystem using inotify API and generate events from changes. I intend to maintain this package as part of the DPMT.
