Re: xz backdoor
On Sun, Mar 31, 2024 at 09:53:06AM -0300, Carlos Henrique Lima Melara wrote: > Hi, > > On Sun, Mar 31, 2024 at 02:31:37PM +0200, Pierre-Elliott Bécue wrote: > > > I would also be happy if it helps my fellow DDs to try making an article > > about some basic crypto concepts regarding PGP, RSA et al. But not in > > the same piece I guess. > > My suggestion is to create a wiki page with these concepts plus a guide > on best practices dor the gpg key (subkeys + hsm - yubikey and others). > Didn't DKG start something like this some time ago? Or am I mis-remembering? Regards, -Roberto -- Roberto C. Sánchez
Re: xz backdoor
On Sun, Mar 31, 2024 at 01:20:39AM +0200, Adrian Bunk wrote: > On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote: > >... > > I'd be happy to have Debian France care about buying and having yubikeys > > delivered to any DD over the world. > > Including Russia? > Supporting DDs in Russia would definitely demonstrate a commitment to geographic diversity. Regards, -Roberto -- Roberto C. Sánchez
Re: Questionable Package Present in Debian: fortune-mod
Hi Wouter, I think that you and I are actually in agreement. On Mon, Aug 21, 2023 at 06:06:34PM +0200, Wouter Verhelst wrote: > On Sat, Aug 19, 2023 at 02:28:22PM -0400, Roberto C. Sánchez wrote: > > On Sat, Aug 19, 2023 at 07:11:11PM +0200, Dominik George wrote: > > > >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. > > > > > But we have established criteria, > > We have not. > We do and the point that I was making was that the FTP masters have criteria for acceptance/rejection of packages from the archive (describing the handling of a number of different situations). By my statement I was trying to communicate that the FTP masters are not charged with policing the content of the archive for "offensive" content and that their focus is, and should remain, on the duties connected with their established criteria. Paul did respond and pointed out that there are established criteria, but that those criteria do not represent everything that the FTP masters consider in the accept/reject process. However, even that being the case it doesn't change the point that I made. > https://www.debian.org/code_of_conduct.en starts off with: > > "The Debian Project, the producers of the Debian system, have adopted a > code of conduct for participants to its mailinglists, IRC channels and > other modes of communication within the project." > > Packaged software is not a "mode of communication within the project". > The code of conduct, therefore, does not apply to it. > I agree 100% here. It is the only sensible way to interpret the Code of Conduct and its intended application. > We may decide that certain language is inappropriate in our packages, > and if so, you can start censoring packages in the archive under the > code of conduct. I made a similar suggestion, though in a more oblique way: That would seem to be the sort of question that needs to be resolved adequately, so that we can stop abusing the Code of Conduct in this way. There are technical reasons for packages to be rejected or removed, and there are non-technical reasons (currently, things like license, abandoned, etc). It would be necessary to add a new non-technical criteria that described the boundaries with sufficient clarity to allow the responsible parties to evaluate the various situations against those criteria/boundaries. Even something as simple as "a package may be rejected and/or removed if its contents or some subset thereof would reasonably be considered a violation of the Code of Conduct if directed at an individual or group via a means otherwise subject to the Code of Conduct." > I make no statement as to whether I believe that is the > right course of action at this point; bring it to a GR and you will see. > The same can be said for me. > Absent that action, however, the code of conduct does not apply to > relevant content of packages in the archive. > Agreed. That is also why I have sent a message to #1024501 asking if it can be closed. Regards, -Roberto -- Roberto C. Sánchez
Re: Questionable Package Present in Debian: fortune-mod
On Sat, Aug 19, 2023 at 02:35:18PM -0400, Paul R. Tagliamonte wrote: > On Sat, Aug 19, 2023 at 2:29 PM Roberto C. Sánchez wrote: > > The reasons why the FTP masters might reject a package from the archive > > are public [0]. Nowhere on the list is there an entry that says > > "somebody doesn't like this package" or "it has stuff that might offend > > someone" as a valid reason to either prevent a package entering Debian > > or to precipitate its removal. > > This list is not complete nor authoritative. > Ah, that's good to know. I perhaps should have phrased my statement a little differently, so as to not give the impression that I was assuming some level of authority. > Without an ftpteam hat on, but my point of view -- I believe the team > would absolutely reject a package only based on its name (see: > #914179). > That's precisely the sort of Code of Conduct abuse that is at issue here. It was wrong then, and it is wrong now. > FWIW, I've tried hard not to provide input on this thread, since it > doesn't seem like I have anything to add, but I will note we wouldn't > allow a source package in sid with DFSG non-free contents, even if > they're not in the .deb. This makes sense and it is consistent with a sensible view of what it means to "distribute" a package (in binary and in source forms). I am fairly certain that this has been discussed on the various mailing lists a few times since I've been in the project, so it is not at all surprising. > The question is do we treat content in > violation of project norms as seriously as we treat nonfree? > That would seem to be the sort of question that needs to be resolved adequately, so that we can stop abusing the Code of Conduct in this way. There are technical reasons for packages to be rejected or removed, and there are non-technical reasons (currently, things like license, abandoned, etc). It would be necessary to add a new non-technical criteria that described the boundaries with sufficient clarity to allow the responsible parties to evaluate the various situations against those criteria/boundaries. Even something as simple as "a package may be rejected and/or removed if its contents or some subset thereof would reasonably be considered a violation of the Code of Conduct if directed at an individual or group via a means otherwise subject to the Code of Conduct." Regards, -Roberto -- Roberto C. Sánchez
Re: Questionable Package Present in Debian: fortune-mod
On Sat, Aug 19, 2023 at 07:11:11PM +0200, Dominik George wrote: > >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. > But we have established criteria, so perhaps we should focus on ensuring existing and new packages meet the established criteria and, where needed, we update the critieria via the appropriate mechanism. > 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. > And "our infrastructure must be able to host everything we intend to distribute" is one of our established, and very sensible, criteria. > 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. > I am pretty sure that you would be wrong. In my experience, the FTP masters take their jobs very seriously and they have a well established practice of clearly communicating the reasons for rejecting packages. Again, these reasons are not arbitrary, but rather they are governed by established criteria (e.g., license suitability, package name collisions, archive space constraints, etc). At the same time, removals also are governed by existing criteria. Things like lack of maintainer attention, causing disruption to other packages in the distribution, and similar, are TTBOMK valid reasons for removing a package. The reasons why the FTP masters might reject a package from the archive are public [0]. Nowhere on the list is there an entry that says "somebody doesn't like this package" or "it has stuff that might offend someone" as a valid reason to either prevent a package entering Debian or to precipitate its removal. > There is no reason to handle fortunes-off any different. > Agreed, if you mean "there is no reason to handle fortunes-off any differently from any other package". While a great deal of the content in fortunes-off is personally offensive to me (as is the case with content in the other packages I noted elsewhere in this thread), using the Code of Conduct as a justification for its removal is absolutely wrong. The content in those packages cannot, by any reasonable stretch, be considered to fall within the scope of the Code of Conduct. So, if there is a valid technical or policy reason for excluding the package, then by all means go ahead (and good riddance to the package). But if there is not, let's not abuse the Code of Conduct or any other unrelated policy just because it makes a few people feel good. If you really want to see those packages gone because they give you or someone the wrong feels then it is necessary to first establish the policy under which such can be done, because there is currently no such policy. If, instead, the Code of Conduct is successfully weaponized in order to force the removal of any package from the project, then it will simply be proof that the fears of those who warned that the existence of the Code of Conduct would eventually lead to its abuse and weaponization may have in fact been well founded. Regards, -Roberto [0] https://ftp-master.debian.org/REJECT-FAQ.html -- Roberto C. Sánchez
Re: Questionable Package Present in Debian: fortune-mod
On Fri, Aug 18, 2023 at 02:39:00PM -0400, Thomas Ward wrote: > >This is not yet removed if I read the changelog from Debian.There are >additional components in the source code which quote these that suggest it >may be prudent for a complete deletion. Downstream in Ubuntu, this >package was removed due to violation of the Ubuntu Code of Conduct [2], >and as the package in Ubuntu and the package in Debian are identical to >each other, it may be prudent for the Debian community to remove the >package in Unstable and Testing for similar reasons. However, this was >extended to the source package as the *source contents* contain the >offensive wording, etc. > >Can we put this package into the 'considered for removal' list or simply >remove the package as violation of the Debian Code of Conduct from all >releases? > I will offer the classic, "if you don't want to be offended, then don't install the package or look at its sources." I mean, if you're going to wave the code of conduct around (or Andy in the case of the initial report), then perhaps we ought to distinguish between what the code of conduct was very clearly intended to govern, i.e., personal communication between participants in the various means of communication available to participants in the Debian project, and what is contained in fortunes-mod (and other packages*), which is written content originating from various sources, none of which was created or communicated in a way which any reasonable interpretation of the code of conduct would cover. * I'll return to the other packages in a moment. However, that sort of thing seems never to be adequate for those who seem to insist on policing everyone and everything for the sake preventing the delicate sensibilities of who knows whom from being offended, as evidenced by the willingness to blatantly abuse the code of conduct to contort it to cover something it plainly does not cover, nor was it intended to cover. All of that said, let's return to the other packages. If content in fortunes-mod can be labeled homophobic, misogynist, misandrist, racist (whatever meaning happens to be attached to those words at the moment), then the same can be said of a substantial fraction of the content in fortunes-es. The similarly offensive content in fortunes-es should result in its removal. Also, if quoting Mein Kampf or anything else from Hitler is problematic, then perhaps fortune-anarchism (source package blag-fortune) should also be considered for removal. It includes quotes from numerous individuals who have themselves engaged in terrorism or other violence toward individuals and groups, supported those who have engaged in such activities, or been otherwise complicit in such. So, let's at least be consistent. Regards, -Roberto -- Roberto C. Sánchez
Re: Patch apply failed for 7.74 bullseye curl
Hi Avinash, First, a few items to help you be able to better find assistance on this and other Debian lists: 1. please don't top post 2. please prefer plain text to HTML and images 3. don't CC list participants unless they specifically request it On Mon, Feb 13, 2023 at 02:06:20PM +0530, Avinash Roy wrote: >Hi Roberto, >Thank you for pointing out the error in the subject line. I have fixed >that and yes it's for bullseye curl. >The below packages are used to create lib: >[1]http://deb.debian.org/debian/pool/main/c/curl/curl_7.74.0.orig.tar.gz > > [2]http://deb.debian.org/debian/pool/main/c/curl/curl_7.74.0-1.3+deb11u3.debian.tar.xz >I have attached the image from my script. >Please have a look. >[3]image.png It looks to me like you are relying on plain tar. Note that Debian packages are easier to work with if you use the right tools. I would recommend that you look at the dget and dpkg-source utilities for fetching and unpacking Debian source packages. Regards, -Roberto -- Roberto C. Sánchez
Re: Patch apply failed for curl 7.74 buster
On Fri, Feb 10, 2023 at 02:33:05PM +0530, Avinash Roy wrote: >Hello All, >I was trying to apply the patch curl_7.74.0-1.3+deb11u5.debian.tar.xz and >got the below issue. How could I fix these? Your subject line says 'buster' but the version you indicate is from bullseye. Are you certain that you have a matching upstream version? How did you obtain the source package? How are you unpacking it? What exact commands did you use? Regards, -Roberto -- Roberto C. Sánchez
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 05:48:56PM +0500, Andrey Rahmatullin wrote: > On Thu, Jul 14, 2022 at 08:45:24AM -0400, Roberto C. Sánchez wrote: > > > > Filing the ITP then immediately uploading seems really sensible, > More sensible than not filing it? > This defeats both purposes of an ITP: getting it discussed and working as > a mutex for people who are thinking about packaging the same software. Are > there other purposes? > Filing the ITP and then uploading immediately seems like it still fully allows for both things you describe. The discussion can take place as the package waits in NEW (which can be highly variable, from days to weeks, even to months). Revisions can be uploaded (if called for based on the discussion) without losing the place in NEW. As far as the mutex aspect, suppose I have some software that I want to package. I experiment and create a package before filing an ITP, for reasons, and then decide, "yes, I do want to upload this". First I search existing ITPs and see if someone has expressed an interest in working on this. If so, I communicate and coordinate with that person. If not, I file a new ITP. At that point, I am faced with a question, "how long to wait before uploading?" We can make the argument that whatever delay is chosen is likely to be insufficient for any of a number of reasons. So, then what's the difference with just uploading as soon as the ITP is filed? If someone comes along during the period where the package is in NEW and has an interest, then a simple "hey I'm also interested in packaging this, can we join forces?" seems like the thing to do. Perhaps then it might be that ITP should not be mandatory. If we substitue "search NEW and search open ITPs" for "search open ITPs" then the main reason to have ITPs would be for the instance where someone has the intention of packaging something but not until some time in the future. This might be because the person lacks sufficient time in the present, because upstream has not yet made a first release suitable for upload, or any of a number of other reasons. In any event, this seems like something that each maintainer can reasonably judge based on the circumstances. Regards, -Roberto -- Roberto C. Sánchez
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 02:31:22PM +0200, julien.pu...@gmail.com wrote: > Hi, > > Le jeudi 14 juillet 2022 à 14:16 +0200, Marc Haber a écrit : > > On Thu, 14 Jul 2022 12:54:52 +0100, Steve McIntyre > > wrote: > > > And I see you uploaded ~immediately - why even bother with an ITP? > > > > Is it proper procedure to upload without an ITP? > > > > No ; I have to admit a large percentage of the new packages I upload > get their ITP minutes before the package is ready. > > Basically: I wait for the bug number before pushing to salsa & NEW. > It's been a while since I've packaged something entirely new, but this is also how I have approached it. Especially during periods when it might take months to make it through NEW, waiting an additional week or two for discussion around an ITP (especially when the vast majority of ITPs actually never elecit any sort of response from anyone), seems rather pointless. Filing the ITP then immediately uploading seems really sensible, especially since in the event of a mistake it is trivial to email ftp-master requesting a REJECT, which IME is usually something they do right away. Regards, -Roberto -- Roberto C. Sánchez
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, Jul 14, 2022 at 11:14:43AM +0100, Steve McIntyre wrote: > edw...@4angle.com wrote: > > >Package: wnpp > >Severity: wishlist > >Owner: Edward Betts > >X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org > > > >* Package name: gender-guesser > > Version : 0.4.0 > > Upstream Author : Israel Saeta P�rez > >* URL : https://github.com/lead-ratings/gender-guesser > >* License : GPL-3 & GFDL-1.2+ > > Programming Lang: Python > > Description : Guess the gender from first name > > Oh, not *another* package that tries to guess things from names. > > Do you have a real use for this package? Why in the world is that even a relevant question? There are plenty of packages in the archive which are useful to essentially nobody apart from the maintainer and there are even packages which are maintained without being useful to the maintainer at all (but rather useful to others). > There are a *lot* of issues > in this area, and mis-gendering people is not something to risk > lightly... > "There are a *lot* of issues in this area" seems rather nebulous. In which area? Given the fact that we have clear and rather unambiguous guidelines for what constitutes software which is appropriate for inclusion in the archive, and given that on its face this software does not seem to be in conflict with any of those guidelines, what then is the problem? BTW, I'm not interested in any sort of "well I don't like ..." or "such and such could offend so and so ..." sort of arguments. Please provide an objective and technically-based reason for why this particular package should not be in the archive rather than hand-wavy arguments without any actual substance. Otherwise, it will appear as though you are simply attempting to conform everyone else to your own personal view on things. I think we can all agree that "there are a *lot* of issues" with such an approach. Regards, -Roberto -- Roberto C. S�nchez
Re: Lintian breaks existing lintian-overrides due to added []
On Wed, Jun 29, 2022 at 02:49:35PM +0200, Andreas Tille wrote: > Hi, > > I realised that lintian (at least) starting with version 2.115.1 (may be > earlier) wraps file names into [] which breaks existing > lintian-overrides. Random example: > > > https://salsa.debian.org/med-team/biomaj3-user/-/blob/master/debian/lintian-overrides > > now becomes invalid by lintian claiming > > W: python3-biomaj3-user: mismatched-override script-with-language-extension > usr/bin/biomaj-users.py [usr/share/lintian/overrides/python3-biomaj3-user:2] > W: python3-biomaj3-user: script-with-language-extension > [usr/bin/biomaj-users.py] > > I consider these [] not helpful since it breaks lots of > lintian-overrides with no visible advantage. Could this change in > lintian please be reverted? Or perhaps make the new format default (I quite like it better from a visual perspective), and issue a deprecation warning for the old format (e.g., when -I is specified). Then perhaps after the next stable release drop the old format. > > Thanks a lot for maintaining lintian in any case > +1 Regards, -Roberto -- Roberto C. Sánchez
Re: [RFC] changes to rsyslog
On Sat, Nov 13, 2021 at 10:43:48PM +0100, Michael Biebl wrote: > On 13.11.21 22:40, Roberto C. Sánchez wrote: > > On Sat, Nov 13, 2021 at 10:32:23PM +0100, Michael Biebl wrote: > > > > > > - Existing systems will continue to have rsyslog installed (but they can > > > safely uninstall rsyslog) > > > > > I'm not sure if this a directly relevant question (apologies if it is > > not), but is there migration path to allow bringing legacy log data > > *into* the systemd journal[*] to allow for accessing log data through a > > single interface/mechanism after making the transition? > > > > Well, exisisting log data in /var/log will continue to exist. > > And anything that has been logged via syslog() will end up in the journal. > > Does that answer your question? Not really. I guess a better phrasing of my question is: what method or methods are available for viewing/searching existing log data in /var/log and log data contained in the systemd journal in a consolidated way? Regards, -Roberto -- Roberto C. Sánchez
Re: [RFC] changes to rsyslog
On Sat, Nov 13, 2021 at 10:32:23PM +0100, Michael Biebl wrote: > > - Existing systems will continue to have rsyslog installed (but they can > safely uninstall rsyslog) > I'm not sure if this a directly relevant question (apologies if it is not), but is there migration path to allow bringing legacy log data *into* the systemd journal[*] to allow for accessing log data through a single interface/mechanism after making the transition? Regards, -Roberto [*] whether as part of the transition or as a separate step that can be executed manually -- Roberto C. Sánchez
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 02, 2021 at 04:08:37PM +, Jeremy Stanley wrote: > On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote: > [...] > > Providing "default secure setting" is good message to users. > [...] > > As previously covered, I'd suggest steering clear of referring to > this as adding "default security." That implies APT wasn't already > effectively secure over plain HTTP, and may give a false impression > that HTTPS is addressing gaps in the existing apt-secure design. > > This change is more about recognizing HTTPS as the primary transport > protocol for the modern Web, not sending mixed signals regarding the > general security risks posed by plain HTTP when used for unrelated > purposes, and no longer needing to repeatedly explain to users that > Debian has gone to great lengths to implement package distribution > security which doesn't really depend at all on transport layer > encryption. In this context, it might make sense to describe using HTTPS as the transport for APT operations is providing "default confidentiality". Regards, -Roberto -- Roberto C. Sánchez
Re: Why Vcs-* fields are not at least recommended ?
On Wed, Aug 19, 2020 at 04:33:28PM +0500, Andrey Rahmatullin wrote: > On Wed, Aug 19, 2020 at 07:31:08AM -0400, Roberto C. Sánchez wrote: > > > For non actively maintained packages on could check them into Git > > > oneself and then start a history from there, and potentially update the > > > package. > > > > > I have had good results with snapshot.debian.org. On a few occasions, > > simply downloading each successive version from snapshot.debian.org and > > then using something like 'gbp import-dscs *.dsc' gives more than > > sufficient version history. Granted, that has limitations, but it is > > available right now. > gbp import-dscs --debsnap > The only thing I don't like about the debsnap option is that it does not seem to have a way to limit the number of snapshots that are retrieved or to specify the versions of interest. For instance, if I only want to see the versions of a package that constitute stable security updates, I might do something like this: debsnap -v -d . -f foobar --first 1.2-3 --last 1.2-3+deb9u5 Then: gbp import-dscs *.dsc If the --debsnap option to import-dscs has that capability then it must not be documented. Regards, -Roberto -- Roberto C. Sánchez
Re: Why Vcs-* fields are not at least recommended ?
On Wed, Aug 19, 2020 at 12:49:11PM +0200, Ulrike Uhlig wrote: > Hi Alexis, > > On 18.08.20 23:10, Alexis Murzeau wrote: > > > I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or > > Vcs-) > > are not recommended (or maybe even strongly recommended) ? (I mean here > > that I think > > having Vcs-* fields should be recommended for active packages) > > > There is no lintian tag for missing Vcs-* fields (not even a low severity > > one, > > but I don't know if it's because of lack of interest or because of the > > policy). > > If one uses lintian in its pedantic mode, and a package is > co-maintained, i.e. has a Maintainer and Uploader field, then lintian > does recommend using a VCS: > https://lintian.debian.org/tags/co-maintained-package-with-no-vcs-fields.html > > I agree that it might be useful to extend this tag to non co-maintained > packages as well, potentially at least in pedantic mode. > > > Maybe the fact that we still have the package' source tarballs for each > > released version is enough, but this loose the VCS history and ongoing work > > in > > case someone else wants to contribute too. > > I fully agree with you here. > > For non actively maintained packages on could check them into Git > oneself and then start a history from there, and potentially update the > package. > I have had good results with snapshot.debian.org. On a few occasions, simply downloading each successive version from snapshot.debian.org and then using something like 'gbp import-dscs *.dsc' gives more than sufficient version history. Granted, that has limitations, but it is available right now. Regards, -Roberto -- Roberto C. Sánchez
Re: Build-Depends-If-Available
On Sun, Aug 09, 2020 at 03:22:20PM +0100, Barak A. Pearlmutter wrote: > I'm maintaining mlpack. It is able to generate julia bindings, so on > architectures in which julia is available I'd like to generate julia > bindings, and this requires julia to be installed at build time. I've > set up debian/rules to check if julia is installed, and set > configuration options appropriately. Similarly, it seems best to build > the package using clang if possible, but if clang isn't available it > can be built using GCC (assuming you build single threaded and roughly > six hundred mysterious GCC space-saving options are set). > > I thought I could accomplish this with build dependencies like > > Build-Depends: julia | hello, ..., clang | buthead > > where hello and buthead are stupid little packages that are available > on all architectures but would not otherwise be installed. Ugly, sure, > but maybe it would get the job done. Nope! The build daemons just try > to install julia and clang and fail if either's not available. I've > also seen > > Build-Depends: julia | dpkg, ..., clang | dpkg > > but that also doesn't work. > > I could check which architectures have julia, and which have clang, > and list them. > > Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel > armhf i386 ...] > > but that makes my skin crawl because it is highly non-future-proof and > violates all sorts of software engineering principles. > > Anybody know if there's a good solution to this problem? > A slightly less bad approach might be: Build-Depends: julia [! ! ...], clang [! ! ...] Regards, -Roberto -- Roberto C. Sánchez
Re: DEP-14: renaming master to main?
On Mon, Jun 22, 2020 at 10:13:31PM +0100, Colin Watson wrote:
> On Mon, Jun 22, 2020 at 05:50:02PM +0200, Michael Biebl wrote:
> > there has been a lot of talk recently about how master is a loaded term
> > that should be avoided.
> > If I read the news correctly, github and others are going to change the
> > default master branch to main.
> > I don't really have any strong opinion on that matter myself.
>
> For a while I'd thought that it was relatively harmless in comparison to
> full-blown uses of master/slave metaphors, but I saw some analysis of
> the history recently that pointed out that git got it from BitKeeper
> which did in fact use a master/slave metaphor [1].
>
Calling that email an analysis is rather charitable. It is really just
a bunch of nonsense. In fact, it is rather impossible to say with any
degree of certainty what thought (or lack thereof) went into the choice
by Linus adopt the "master" terminology in Git. That makes the whole
discussion rather pointless, or a distraction. Rather than focusing on
"why", would it not be better to just take the opportunity to make an
improvement?
> > That said, what I care about is consistency and predictability across
> > the archive.
> > If we deem that "main" is a better term, should we change the defaults
> > in salsa/gitlab and maybe update DEP-14?
>
> I think my ranked preferences are:
>
> 1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a
> nice allusion to this list)
> 2. trunk (historical familiarity from other VCSes)
> 3. main or maybe mainline (some tab-completion similarity to master,
> though the confusion with components in a Debian context is
> unfortunate)
> 4. further discussion / something else / etc.
> 5. stick with master
>
If we are going to make a change then the motivation should be technical
in nature, which should inform the choice and which should cause us to
ensure that any change made is an improvement. Regardless of whether
the term "master" is harmless, causing imagined harm, or causing real
harm, at present there is a rather fortunate opportunity to make an
objective usability improvement in what has perhaps become the most
common and universal tool used by software developres the world over.
Thinking about the way in which Git is used (regardless of chosen
workflow, paradigm, etc.) names likes "main" and "default" are just as
unclear as "master" in terms of conveying a purpose for the branch.
Sort of like the old dialogs ("Save & exit? Yes/No" and "Discard & exit?
yes/No") that essentially forced you to think about the meaning of each
available choice. Nowadays we use button labels like "Save/Discard"
instead of "Yes/No" because it just works better by reducing the
cognitive burden on the user and making it more likely that the result
of the action will match the user's expectation.
The prevalence of tools that previously used "trunk" makes that not a
terrible choice. However, there are clearly better options.
That said, being that Git as a tool is designed and targeted for
software developers to work on source code (an activity universally
called "development"), renaming "master" to "devel" would mark a
usability improvement. In particular, for any given project I don't
have to figure out, "is 'master' the branch where active development
takes place or does development take place elsewhere and 'master' is the
branch from which releases are made?" A branch called "devel" would
unquestionably be where active development is taking place.
Other branch names could then be chosen based on the needs of the
project, like "test", "stage", & "prod", or "rc" & "release", or
whatever.
Regards,
-Roberto
--
Roberto C. Sánchez
Re: FTP Team -- call for volunteers
On Sat, Mar 14, 2020 at 09:18:48PM +, Neil McGovern wrote: > Hi debian-project and ftpmaster folks, > > On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: > > - cope well with flames in response to your decisions > > > - after training, comfortable with being on the other end of the > > ftpmaster@ alias, which receives a huge volume of > > not-always-pleasant messages daily. > > I hope I am not the only one to be deeply concerned that this should be > a requirement on volunteers. For me, it is absolutely unacceptable that > people should put up with unplesentness or flames that come from doing a > difficult job. Putting this in the requirements is, for me, a failure of > the project. > > Sean: do you have any ideas on how we can reduce this aspect of the > valuable work that ftpmasters do? Do you have some (anonymised) examples > of the areas of abuse that you receive perhaps? > The fact is that given the length of time packages can wait for NEW processing and the amount of effort package maintainers put into packaging, it is understandable that they would be frustrated at the rejection of a package. That said, it does not make flaming the FTP an acceptable response and is certainly not going to produce any positive result. But it is not clear that it would be possible to prevent such a thing. It seems like if NEW processing only took a short time (perhaps 1 or 2 weeks), then a rejection would be less frustrating. However, a rejection after waiting 11 or 12 months (or longer) and no response to requests for additional guidance when something is unclear are difficult to deal with from the package maintainer side. The delays may be unavoidable, but any measures to minimize them would go a long way to reducing the likelihood of flame responses to rejection mails. Regards, -Roberto -- Roberto C. Sánchez
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 02:41:59PM +0100, Geert Stappers wrote: > On Sat, Feb 15, 2020 at 08:33:25AM -0500, Roberto C. Sánchez wrote: > > On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > > > Hi folks, > > > > > > I am maintainer for mg, currently on salsa. Problem is, upstream > > > doesn't release tar balls anymore, but moved the code to github. > > > No tags. > > > > > > How can I tell Salsa? Should I drop the upstream and pristine-tar > > > branches on Salsa and integrate the repository on github? Would > > > you suggest to move the debian part to github instead? > > > > > > Every helpful comment is highly appreciated > > > Harri > > > > > You could probably add the GitHub project as a new remote, then through > > gbp.conf (assuming you are using gbp) you can name a new branch as > > 'upstream'). Alternately, you could rename the current upstream branch > > as something else and then checkout the master branch from the GitHub > > remote as 'upstream' in your repository. You might also have to make > > some minor tweaks, but the above are the major steps. > > Please state some examples where that is done. > I'm not aware of any, else I would had given them. Regardless, gdp doesn't really care the source of its 'upstream' branch, nor its name if given in the configuration. Of course, if upstream is no longer releasing tarballs and Harald decides to track the GitHub upstream project as the 'upstream' branch in the repository where the Debian package is maintained, then the pristine-tar will probably have to go. But that seemed to be understood from the initial message. Either way, gbp is sufficiently flexible and configurable to be used in the way Harald describes. Regards, -Roberto -- Roberto C. Sánchez
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
On Sat, Feb 15, 2020 at 12:05:29AM -0500, Jerome Charaoui wrote: > > Following the announcement of the DebConf20 location, our desire to > participate became incompatible with our commitment toward the Boycott, > Divestment and Sanctions (BDS) campaign launched by Palestinian civil > society in 2005. Hence, many active Montreal-based Debian developpers, > along with a number of other Debian developpers, have decided not to > travel to Israel in August 2020 for DebConf20. > Would it be possible to not constantly air our personal political opinions and grievances on Debian lists? Especially as part of something that goes to an -announce list. If anything, this is harmful to Debian as a project. What would have been so difficult about something like "for those in the Debian community who for whatever reason cannot attend DebConf 2020 in Israel, there will be a mini-DebConf in Montreal" and so-on and so forth? Regards, -Roberto -- Roberto C. Sánchez
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > Hi folks, > > I am maintainer for mg, currently on salsa. Problem is, upstream > doesn't release tar balls anymore, but moved the code to github. > No tags. > > How can I tell Salsa? Should I drop the upstream and pristine-tar > branches on Salsa and integrate the repository on github? Would > you suggest to move the debian part to github instead? > > Every helpful comment is highly appreciated > Harri > You could probably add the GitHub project as a new remote, then through gbp.conf (assuming you are using gbp) you can name a new branch as 'upstream'). Alternately, you could rename the current upstream branch as something else and then checkout the master branch from the GitHub remote as 'upstream' in your repository. You might also have to make some minor tweaks, but the above are the major steps. Regards, -Roberto -- Roberto C. Sánchez
Re: Can Debian packaging changes require a CLA?
On Fri, Feb 14, 2020 at 03:46:18PM +, Dimitri John Ledkov wrote: > Can a Debian Package Maintainer require CLA for accepting packaging > changes and distro patches to be uploaded into Debian itself? > > (case in point, debian maintainer & upstream wear the same hat, and > maintain upstream code & packaging on github.com, under a company org > with a CLA bot, rejecting debian/* merge proposals until CLA is > signed) > > I didn't find things specifically about this in the policy and/or in > the dfsg-faq and the three classic tests (desert island / dissident / > tentacles of evil) do not fit the bill quite right. > Have you considered it this way? As Debian maintainer of some package you are able to decide whether or not you accept contributions to that package based on your own criteria (or your employer's in this case)? If the criteria are too onerous such that they discourage contributions then there is a possibility that eventually someone may come along and repackage it under a different name; essentially your criteria could precipitate a fork. In principle, there seems to be nothing that would prevent such a requirement (i.e., a CLA), but in practice it is likely to irk potential contributors. Regards, -Roberto -- Roberto C. Sánchez
Re: Is distro-tracker accessible by some sort of API?
On Fri, Jan 17, 2020 at 02:41:26AM +, Paul Wise wrote: > On Thu, Jan 16, 2020 at 7:06 PM Roberto C. Sánchez wrote: > > > I've read the distro-tracker documentation and it seems like interaction > > is by visiting with a web browser or via email. Is there an official or > > even unofficial API for access to data in distro-tracker? > > There are a few APIs defined in the URL configuration: > > https://salsa.debian.org/qa/distro-tracker/tree/master/distro_tracker/project/urls.py > > Which kind of APIs were you looking for and what did you intend to use > them for? Most of the tracker data is just imports from elsewhere (UDD > mostly) so it might be better for you to use that data instead. > OK. That's helpful. I'm sure I have heard of UDD over the years and just not really paid it much mind since it wasn't relevant to my needs at the time. My initial thought was to query the tracker for a given package to determine its availability. The particular question I'm trying to answer is: does source package 'foo' exist in release 'bar'? Looking at the UDD wiki page and the associated examples, it seems like the query I need is something roughly like: SELECT COUNT(*) FROM public.packages WHERE source='foo' AND release='bar'; Is this the best approach? Regards, -Roberto -- Roberto C. Sánchez
Is distro-tracker accessible by some sort of API?
I've read the distro-tracker documentation and it seems like interaction is by visiting with a web browser or via email. Is there an official or even unofficial API for access to data in distro-tracker? Regards, -Roberto -- Roberto C. Sánchez
Re: Be nice to your fellow Debian colleagues
On Wed, Jan 01, 2020 at 02:09:46PM -0500, Roberto C. Sánchez wrote: > [stuff] I just saw Sam's message after I sent my own. I agree that this discussion has gone past the point where it is useful. Apologies for the noise. -- Roberto C. Sánchez
Re: Be nice to your fellow Debian colleagues
n any such thing now nor in the past; I would expect that it would not in the future. Note that it is certainly possible to argue that any number of decisions are effectively a choice to "stop being the universal OS"; for example, dropping official support for previously support hardware architectures (e.g., alpha, hppa, itanium, m68k, etc.). Those decisions were made based on a variety of technical criteria, they likely resulted in some individuals somewhere being upset, yet they were necessary for some reason or another. > These days, when a successful team wins at a sporting event, it > encompasses all the participants and appreciates them all as > contributing, it isn't just the on field players, even the on field > players get [and deserve] most of the glory. Teams are made up of > players in many fields, just peruse the credits at the end of movies, > there are shed loads of people involved, one way or another. > I agree 100% here. In fact, Debian does an amazing job of showing appreciation for the entire community in numerous ways. But to use your example of looking at the movie credits, the assistant best boy electric grip does not get the same say (or really any say) in the creative direction of the movie; that say is reserved for the producers, directors, and possibly the talent. The assistant best boy electric grip is shown appreciation by being remunerated for his efforts and by being listed in the credits. > Do you think that any Debian advocate or user should not be able to be > part of Debian's success without them needing to be DDs? That would > be a very shallow view towards anyone not "elite" enough to be a DD. > Remember, it isn't so much against DDs, not at all, it is more about > the greater good of Debian and from a far more wide reaching view than > the DDs alone can have. > And if the Debian project were a movie production and someone wanted to influence the direction of the project, we would say, "invest in the production funds enough to be considered a producer and then you can have your say." Yet, the Debian project has many ways for those who are not DDs to influence the direction of the project. You are simply focusing on one of the very few mechanisms which is reserved only to DDs. Why do you ignore the other avenues available to you? > It is neigh on impossible for everyone to have a say, but it isn't > beyond the realms just DDs to think beyond themselves and for the > greater good of the project. > I think beyond myself when it comes to decisions I make in the course of my Debian work and every DD I know does that. To imply otherwise, as you have done, is rather unfair. Incidentally, this is part of what makes me think that you are personally offended by some of the recent events and it seems that may be the cause of the lack of objectivity in your communication. > Would you want a project that is only "good" for 1,100 to 1,200 DDs or > would you want what has been Debian's goal of being a universal Linux, > good for so many more? > Ibid. > Let's be positive about this and find a way to be more inclusive of > the greater Debian population; it should be a win for everyone. > There are countless ways for anyone, DD or not, to influence the direction of the Debian project. So, perhaps all that is needed is to begin taking advantage of those ways, rather than complaining about the one way that, for very good reason, is reserved only for DDs. Regards, -Roberto [0] https://www.debian.org/social_contract -- Roberto C. Sánchez
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 12:32:24PM +0100, Paul Gevers wrote: > > [1] Source packages that build binaries unknown to the archive currently > need these binaries to be uploaded by the maintainers for reviewing by > ftp-master in NEW. IIRC there have been multiple proposals to avoid > these binaries from either being needed or being uploaded to the Debian > archive, but so far the current tooling requires this. On the other > hand, the release team has decided that we want all binaries in our > releases to be build on buildd. For that we have enhanced our migration > software to check for non-buildd uploads and add a block for them. > Unfortunately, once uploaded we can't fix the situation for arch:all > packages as binNMU'ing arch:all is currently broken. There is slow > progress to improve that situation, see e.g. bug #916601. > I've encountered this issue myself in the past with a SONAME bump in a library package. It was rather surprising. Would it not be possible to eliminate the need for the second unnecessary upload by requiring two signed .changes files to go into NEW? A signed binary changes which would form the basis of the FTP master review and a signed source changes to enter the archive if the package is approved? When I build packages I always end up with both changes files, so requiring both for NEW processing would be a triviality (for me, at least) and eliminate this peculiarity as well. Regards, -Roberto -- Roberto C. Sánchez
Re: default firewall utility changes for Debian 11 bullseye
Hi Arturo! I know that this discussion took place some months ago, but I am just now getting around to catching up on some old threads :-) On Tue, Jul 30, 2019 at 01:52:30PM +0200, Arturo Borrero Gonzalez wrote: > Ok, after a couple of weeks, lets try to summarize: > > On 7/16/19 11:07 AM, Arturo Borrero Gonzalez wrote: > > > > This email contains 2 changes/proposals for Debian 11 bullseye: > > > > 1) switch priority values for iptables/nftables, i.e, make nftables > > Priority: > > important and iptables Priority: optional > > > > Nobody seems to disagree with this point. So I will be doing this soon. > It looks like the situation in sid has not changed yet: (sid)root@build01:/tmp# apt-cache show iptables nftables | egrep 'Package|Version|Priority|^$'Package: iptables Version: 1.8.4-1 Priority: important Package: nftables Version: 0.9.3-1 Priority: optional Do you still intend to make the change in priorities? > > 2) introduce firewalld as the default firewalling wrapper in Debian, at > > least in > > desktop related tasksel tasks. > > > > There are some mixed feelings about this. However I couldn't find any strong > opinion against either. > > What I would do regarding this is (just a suggestion): > * raise priority of firewalld > * document in-wiki what defaults are, and how to move away from them > * include some documentation bits in other firewalling wrappers on how to deal > with this default, i.e what needs to be changed in the system for ufw to work > without interferences (disable firewalld?) > I like the idea of documenting this all in a wiki. [Side note: I maintain Shorewall in Debian and since the upstream author announced his retirement eariler this year several of the most active developers/community members (including me) have begun the process of taking over the project from him. One of the items we have discussed support for nftables, so I can see that changing in the coming year, making a wiki page a good choice for where to document Shorewall integration with various Debian parts.] Incidentally, the Debian Installation Guide makes no mention of firewalls or even basic steps to secure the system. If a wiki page is developed that documents the various firewall integration options, it would be nice if it became the basis of a new section in the installation manual (perhaps under section 8, Next Steps and Where to Go >From Here). It may also be a good addition/improvement to the Securing Debian Manual. In any event, I am just offering some thoughts; perhaps they might be of some use. Regards, -Roberto -- Roberto C. Sánchez
Re: apt: deprecate /etc/apt/trusted*
On Sat, Nov 09, 2019 at 06:23:04PM +, Colin Watson wrote: > On Sat, Nov 09, 2019 at 12:29:11PM -0500, Roberto C. Sánchez wrote: > > On Mon, Nov 04, 2019 at 02:27:19PM +0100, Timo Weingärtner wrote: > > > Maybe apt could deprecate /etc/apt/trusted* and apt-key(8) in bullseye > > > and > > > abandon them in bullseye+1. The whole concept of having one keyring that > > > authenticated all sources is wrong. I had my share in making /etc/apt/ > > > trusted.d possible, but now that we have "Signed-By:" it is the inferior > > > solution and thus not needed anymore. > > > > What is the earliest version of apt that supports Signed-By in > > sources.list? I scanned the changelog but it was not immediately clear. > > 1.1~exp9. The commit was: > > > https://salsa.debian.org/apt-team/apt/commit/b0d408547734100bf86781615f546487ecf390d9 > Thanks! Regards, -Roberto -- Roberto C. Sánchez
Re: apt: deprecate /etc/apt/trusted*
On Mon, Nov 04, 2019 at 02:27:19PM +0100, Timo Weingärtner wrote: > > Maybe apt could deprecate /etc/apt/trusted* and apt-key(8) in bullseye and > abandon them in bullseye+1. The whole concept of having one keyring that > authenticated all sources is wrong. I had my share in making /etc/apt/ > trusted.d possible, but now that we have "Signed-By:" it is the inferior > solution and thus not needed anymore. > What is the earliest version of apt that supports Signed-By in sources.list? I scanned the changelog but it was not immediately clear. Regards, -Roberto -- Roberto C. Sánchez
Re: NEW queue and src-only uploads [Re: Bits from the Release Team: ride like the wind, Bullseye!]
On Tue, Jul 09, 2019 at 01:33:49PM +0100, Sean Whitton wrote: > Hello, > > On Mon 08 Jul 2019 at 02:02PM +02, Michael Biebl wrote: > > > I would go even further and drop the (manual) NEW queue for binary-NEW > > packages. > > Is there a good reason why new binary packages need manual processing by > > the FTP team? Couldn't this be fully automated? > > The three things the FTP team check[1] are worth doing again for > binary-NEW packages. In order: there are often lots of new files in an > upload that ends up in binary-NEW so there might be licensing issues; a > new binary package means a new member of the binary package namespace; > it's good to have a second pair of eyes look at your SONAME bump etc. > > [1] https://ftp-master.debian.org/REJECT-FAQ.html right at the top > I've always wondered about this. Why is it, then, that binary-NEW still applies if there have been no source files added/removed? (A SONAME bump possibly being necessitated by some change that does not involve adding/removing/renaming source files.) Following on that, what about a package that does add/remove source files (perhaps many) without a SONAME bump or other change that results in a new binary package? It seems like reviewing the package name space on introduction of a new binary package and an additional review of a SONAME bump are good things and the binary-NEW criteria seem to fit. However, the "there might be new source files with licensing issues" does not seem to be a good fit for binary-NEW criteria. Not to say that it matters much in the context of binary-NEW. But if catching potential licensing issues associated with large source changes is in fact something which the FTP team wishes to be able to do, it probably warrants a different filter than "adds a new binary package to the archive" in order to be effective. Regards, -Roberto -- Roberto C. Sánchez
Re: duprkit User Repository
On Mon, Apr 08, 2019 at 12:57:56PM +, Mo Zhou wrote: > On Mon, Apr 08, 2019 at 08:36:45AM -0400, Roberto C. Sánchez wrote: > > On Mon, Apr 08, 2019 at 11:02:35AM +, Mo Zhou wrote: > > In such a large community of volunteers it may not be enough to propose > > something that is only marginally better because the cost (even just in > > cognitive terms) and effort required for so many individuals to overcome > > inertia is relatively high. > > Linus said that "Talk is cheap, show me the code." > Now I have shown the code and nobody read that. > > The single-file format is not mandatory, and two convertion tools > enables zero-cost convertion: > https://github.com/dupr/duprkit/blob/master/bin/fold > https://github.com/dupr/duprkit/blob/master/bin/unfold > > And the prototype implementation is compatible to the traditional debian/ > directory. See > https://github.com/dupr/DefaultCollection/tree/master/rover-traditional > for the example. > > BOTH single-file format and traditional format are supported. People > could choose and use what they like. > > I admit that I'm quite fond of the proposed single-file format, and > hence didn't mention and compatiblity with traditional format in design. > > > I am not trying to discourage you from your effort, but rather advising > > you that the chances of success would improve if you address the > > principal obstacles to adoption in a holistic way. (As I already > > pointed out, your current approach misses a great deal.) > > What else can I do? Both traditional and single-file formats are > explicitly supported now. > Two suggestions: - Stop claiming that what you propose is "zero-cost", "only 1 second of work", etc.* - Find the individuals who currently experience the greatest pain associated with the problem you are trying to solve and whose pain is relieved by your solution. Get them to adopt it. If it works as well as you say it does, they will be enthusiastic adopters and will have no problem telling others, in concrete terms, how much better your solution is than whatever the current situation is. * Even in a perfect world, nothing is "zero-cost." To a community of contributors whose purpose it is to build an operating system distribution a deep understanding of the components that compose the system and the components used to build the system are effectively a requirement. Thus, if I came along and said, "here, I have a drop-in replacement for utility 'foo', and I call the replacement 'bar', and it supports all the same options as 'foo' so that you can use it without having to think about any differences" I would still expect that there would be a need for me to convince potential adopters that things really work that way. Experience tells us that even "drop in" replacements for things are seldom that "perfect" when it comes to compatibility with whatever they are replacing. Regards, -Roberto -- Roberto C. Sánchez
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Mon, Apr 08, 2019 at 12:29:56PM +, Mo Zhou wrote: > Hi, > > On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote: > > On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote: > > > Hi, > > > > > > As you wish, I added a disclaimer to the toolkit, and replaced every > > > single "Debian" keyword in the repo with "D**ian", except for those > > > in disclaimer. > > > > Perhaps using ".deb" instead of "Debian" or "D**ian" might be more > > practical. After all, the whole exercise seems to be more focused on > > the packaging and distribution of said packages, rather than "Debian the > > GNU/Linux distribution" as a project. If there are places where the > > leading dot might be impractical or confusing, then perhaps "dotdeb" or > > "dot-deb" might be more workable. > > However the idea involves no distribution of any single ".deb" file. > That's more likely a "User Recipe Repository", instead of a "User dishes > Repository". People will ask "where on earth are your .deb files?" if > I put ".deb" to the title. > OK. Thanks for the explanation. It seems like I did not properly grasp that aspect of it. Regards, -Roberto -- Roberto C. Sánchez
Re: duprkit User Repository
On Mon, Apr 08, 2019 at 11:02:35AM +, Mo Zhou wrote: > Hi, > > On Mon, Apr 08, 2019 at 12:37:36PM +0200, Ondřej Surý wrote: > > > > I very much dislike the idea of inventing yet another format. Your > > energy would be much better used if you rather added support for > > external tarballs to the packaging tools (with hashes, etc.) and turn > > this into DEP. > > There is merely a tiny overhead in the plain text formats. Well, people > have different preferences and I still need time to see whether such > proposed formats are fine. > > I found some existing problem, as what I said in the very first > paragraph of the original post. And I think I've already made the > motivation clear there. If the motivation turns to be useful enough, > why should we reject thinking about something new? > > > Debian is not Fedora/Arch/... and whacking the debian/ into a single > > file doesn’t feel like something that would help anything at all. Just > > require git (as AUR4 does). > > Debian is different from the other distros. Particularly, Debian is a > binary-based distribution. By creating such a user packaging repo, some > advantages of source-based distributions could be introduced. > > And most importantly, anyone who dislike the single-file format > could just commit the debian directory to the repo, and remove > the do_unfold() hook from the header script. That's not recommended > but it still work without the single-file format. Anyway the > single-file format is only a part of the idea, and we can remove > it if most people don't like it. > Let me make a suggestion based on something that I learned quite some years ago as a young engineer fresh from school: the best technical solution is only the best overall solution if it also addresses all (or most) of the relevant non-technical factors. Rather than focus on the "tiny" technical overhead, focus on the quality and value of the improvements that justify to a community of thousands of contributors why they should willingly accept the additional cognitive burden of the change you are proposing. If you think about the proposals that have succeeded in becoming de facto or de jure (in the form of debian-policy) standards within Debian, every one of them has required lots of people see why *additional work* for them was beneficial to them *and everyone else* as well. They also had to agree that they themselves and the project as a whole saw sufficient benefit to warrant the change/additional work. In such a large community of volunteers it may not be enough to propose something that is only marginally better because the cost (even just in cognitive terms) and effort required for so many individuals to overcome inertia is relatively high. I am not trying to discourage you from your effort, but rather advising you that the chances of success would improve if you address the principal obstacles to adoption in a holistic way. (As I already pointed out, your current approach misses a great deal.) Regards, -Roberto -- Roberto C. Sánchez
Re: duprkit User Repository
On Mon, Apr 08, 2019 at 10:47:20AM +, Mo Zhou wrote: > Hi, > > On Mon, Apr 08, 2019 at 03:31:21PM +0500, Andrey Rahmatullin wrote: > > On Mon, Apr 08, 2019 at 09:58:26AM +, Mo Zhou wrote: > > > AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild, > > > all of them are single-file format. The advantages of single-file > > > format includes easy distribution, e.g. copying & pasting from > > > webpages (you cannot copy a directory from a webpage). > > > > This only works when you don't need patches. > > The design of "duprkit" didn't forget patches at all. > > There are many ways to apply apply patches: > > 1. Put separated patches to the Collection repository, as per the >collection specification: https://github.com/dupr/DefaultCollection >Then apply it manually in the header script of .durpkg . >This is similar to what AUR does. > If I interpret this correctly, your idea becomes, "use a single file package specification, except for the parts that live somewhere completely external and separate from the package." That seems like you have *increased* the complexity of the packaging format, rathern than decreased it. > 2. If one like, just fold the patches into the .durpkg, which may result >in some extra lines in the .durpkg: > >^ debian/patches/series >foobar.patch >^ debian/patches/foobar.patch >-foo bar >+foobar > >And you may beed to change the source/format accordingly. > >The fact is, any plain file, as long as none of its lines starts with >a single '^', could be folded into the .durpkg or the .f822 file. >Detailed file format specification can be found in the code comments[1] > > 3. Fold the patches into .durpkg, but not in the quilt format. > >^ some-working-directory/xxx.patch >-foo bar >+foobar > >The header script of .durpkg is able to use it. > > 4. may be more? ... > Even these other points seem like they require some effort to "prep" the packaging so that it exists in a single file and would require similar effort to separate the components out. All of this for "copy & pasting from webpages" seems like the epitome of "style over substance". Why on earth is copying and pasting from webpages *so* important that the entire packaging format has to be reworked? If somebody is challenged by the obstacle of 'apt-get source ...' or 'debcheckout ...' then perhaps making the packaging into a single file so that it can be copy/pasted from a webpage might not be solving the correct problem. Regards, -Roberto -- Roberto C. Sánchez
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote: > Hi, > > As you wish, I added a disclaimer to the toolkit, and replaced every > single "Debian" keyword in the repo with "D**ian", except for those > in disclaimer. Perhaps using ".deb" instead of "Debian" or "D**ian" might be more practical. After all, the whole exercise seems to be more focused on the packaging and distribution of said packages, rather than "Debian the GNU/Linux distribution" as a project. If there are places where the leading dot might be impractical or confusing, then perhaps "dotdeb" or "dot-deb" might be more workable. Regards, -Roberto -- Roberto C. Sánchez
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 09:36:25PM -0400, Peter Silva wrote: > >OK for unstable and testing, but I want to provide packages for stable >versions of Debian using a separate repo that will be get frequent >updates, even though the OS is stable. I get that with [4]launchpad.net. >Your proposal makes no version ever available for a stable version. yes, >it contradicts the meaning of stable, but the idea is similar to the idea >of using snaps, where certain applications require current versions, while >most of the OS remains a stable platform. > Then I think that Ben Finney's observation is completely correct. Regards, -Roberto -- Roberto C. Sánchez
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 05:50:37PM -0400, Peter Silva wrote: > >Hiring debian devs to get the packages into debian proper could make >sense. One thing that dampens our enthusiasm for that at the moment is >that our packages are still very unstable, in the sense that the we are >releasing materially better version incrementally, say once or twice a >month. It is sort of analogous to a rolling release. That works fine >with the launchpad model, but if it gets baked into debian, then we need >to support some random old version for many years. Perhaps once it has >stabilized, that would be something we could work with, but for now, the >[2]launchpad.net model, which supports backporting seamlesslly and allows >to support the same version on all distro versions, works better for us. >This is something a debian version of launchpad would get us. > You can already accomplish what you are describing today: - have packages uploaded to experimental - upload to unstable and file a release critical bug to prevent it migrating to testing (look at https://bugs.debian.org/915050 for instance) Both approaches get the package into Debian, available to users of unstable and/or experimental, as appropriate, and without risk of the package getting "baked in" to a Debian release for the long term. Regards, -Roberto -- Roberto C. Sánchez
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 10:13:58AM -0400, Peter Silva wrote: >fwiw, our organization doesn't have any debian devs. We have a few >packages that we develop and deploy >for our internal needs, and make available to the internet with public >repositories. they are (perhaps not perfectly) debian compliant packages, >but we aren't blessed debian devs (and frankly cannot be bothered to >become them.) There are many Debian developers who work as consultants specifically on Debian-related work, either independently or as part of a company that offers Debian-related services. Since you have done most of the work, you could easily hire one of those folks to help with a small number of hours worth of effort to take the package through the process of getting it into Debian. You can post to the debian-jobs list or check the Debian consultants page on the main Debian website for candidates. Regards, -Roberto -- Roberto C. Sánchez
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 02:34:05PM +, Mo Zhou wrote: > Hi, > > The problem is not "who is responsible for implementing this", but "is > this valuable enough to implement". > > If a group of people think it worthwhile to do something, they will be > glad to work together on a common belief, spontaneously. I as the > initiator of the idea would definitely take action if I got enough > positive feedbacks. > I recommend that you start implementing something then request feedback. Otherwise the whole exercise is just academic. Regards, -Roberto -- Roberto C. Sánchez
Re: Bug#924270: O: keepassx -- Cross Platform Password Manager
On Sun, Mar 10, 2019 at 08:27:49PM +, Jonathan Dowland wrote: > On Sun, Mar 10, 2019 at 03:14:07PM -0400, Reinhard Tartler wrote: > > I am undecided whether or not this package should be included in Debian > > 10 (aka buster). It clearly is useful to many people, but its long-term > > maintenance is unclear. > > keepassxc is also going to be in Debian 10 (unless something happens to > prevent it), so if the maintenance story is better there, I don't think > there's a use-case for keepassx that is not fulfilled by keepassxc I'd > lean towards dropping keepassx for Buster and possibly even using > package metadata in keepassxc and compat symlinks for a smooth > transition. > As a long-time user of keepassx, though not familiar with Qt and so not really able to help with the maintenance aspect, I would very much like to see the release of Buster have either a well-supported keepassx or a smooth transition to a suitable alternative. If for some reason a direct transition with symlinks and all is not possible, then at least a mention in the release notes (perhaps with instructions on how to manually migrate before and/or after upgrade). Regards, -Roberto -- Roberto C. Sánchez
Re: Salsa CI news
On Mon, Feb 25, 2019 at 02:44:22PM +, Jonathan Dowland wrote: > On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote: > > On behalf of the Salsa CI Team I'm pleased to announce some of the > > changes we've been working on this weekend. We don't have an official > > mailing list, so please excuse us if this is not the place for this > > kind of announcements. > > Thanks for sharing! Personally I think you could consider using > debian-devel-annou...@lists.debian.org (but others may disagree) > At the very least make sure the publicity team knows so it makes it into the next Debian Project News issue. Regards, -Roberto -- Roberto C. Sánchez
Re: Recreating history of a package (was: Re: Reusing source package name of long-removed, unrelated package)
On Wed, Feb 06, 2019 at 05:59:40PM +0100, Carsten Leonhardt wrote: > Ian Jackson writes: > > > There are utilities that will download all revisions of a particular > > package from snapshot.d.o and make them into a combined history. > > Would you care to name those you know of? I have been searching for > something like that but I didn't find anything useful. > Use 'gbp import-dscs' with the --debsnap option. Regards, -Roberto -- Roberto C. Sánchez
Re: Sending using my @debian.org in gmail
On Fri, Nov 30, 2018 at 10:17:47PM +0800, 殷啟聰 | Kai-Chung Yan wrote: > > There is a Gmail trick where you can add one send-as email and provide > > smtp.gmail.com credentials. > > > You might have to create an app password. > > > I think that this guide does something similar to what I did: > > > https://blog.alexlenail.me/i-want-to-send-emails-from-my-google-domains-email-through-gmail-992bb3eae4c9 > > Just got my DD account and got the trick working, thanks for the tips! > > However this worries me. During the setup there is no Debian involvement, and > that means anyone can do the same trick to pretend to own my Debian address. > That is just how email works. With the help of a cooperating mail server (which is trivial to setup) anybody in the world can send mail with any from address that they wish. This problem is not unique to Debian. Regards, -Roberto -- Roberto C. Sánchez
Handling library with unstable ABI in experimental -- suggestions?
I have filed an ITP [0] for the Mongo C++ Driver. So far upstream has not yet declared a stable ABI. As a result, I intend to upload to experimental. I am curious if anyone has suggestions for naming the library package in experimental in such a way that it handles the currently unstable ABI and also leaves the way clear for a properly named library package once the ABI stabilizes and it becomes appropriate to upload to unstable. That said, upstream intends to declare a stable ABI in some months, after which the ABI, SONAME, etc. will be managed sensibly. The upload to unstable will not happen until that has been fully sorted out. Regards, -Roberto [0] https://bugs.debian.org/914573 -- Roberto C. Sánchez
Re: I resigned in 2004
On Mon, Nov 12, 2018 at 07:47:41PM +0100, Tollef Fog Heen wrote: > > (I also wonder if we should just require people to opt in to their > DD-ship on a yearly basis instead of doing most of the WAT/MIA dance. If > people can't be bothered to reply to a single email saying «yup, another > year please» with some reasonable amount of pinging and time to reply, > they are effectively MIA, at least if they haven't let people know on > -private or similar.) > ISTR that UDD tracks the "last appearance" of each developer, with "last appearance" being upload, mailing list post (I think, if signed with the developer's key), etc. The once a year ping then need not be universal and instead only for those who have become dormant based on lack of visible indicators of participation. Regards, -Roberto -- Roberto C. Sánchez
Re: I resigned in 2004
On Sun, Nov 11, 2018 at 03:38:32PM +0100, Dominik George wrote: > > > he agreed with the CoC, > > > > He did not, the CoC didn't exist yet 14 years ago. > > He did, if not before, when he sent his mail to a mailing list > @lists.debian.org. > > He might not have realised that, of course. > I don't think that you can claim that the act of sending a mail to a list @lists.debian.org can constitute an implied agreement to accept and abide by the code of conduct. That is no different than "by reading this, you are bound by these terms." No reasonable person would consider either of those things valid. Regards, -Roberto -- Roberto C. Sánchez
Re: salsa.debian.org: merge requests and such
On Tue, Nov 06, 2018 at 03:43:41PM +, Felipe Sateler wrote: > > I disagree when it comes to the debian namespace, and the documentation > agrees with me[1]. > Interesting. I was not aware of that. Thanks for sharing. Regards, -Roberto -- Roberto C. Sánchez
Re: salsa.debian.org: merge requests and such
On Tue, Nov 06, 2018 at 03:00:03PM +, Matthew Vernon wrote: > > Relatedly, what's the etiquette about commits to master? I recently > discovered that someone else had pushed a commit to the tip of master of > one of the packages I maintain (and not notified me); when I complained > I was told that emailing would be too much effort. Am I wrong to feel > that at least a MR is something I should have expected as a package > maintainer, not just commits to master? > > [I don't really mean to have a go at the person concerned; I'd just like > to know what to expect in future...] > That seems completely reasonable. Making the repository accessible to others is a courtesy that should not be abused. Pushing directly to the master branch of a package for which one is not an active maintainer or contributor is at a minimum impolite. Regards, -Roberto -- Roberto C. Sánchez
Re: PHP Support in Debian
Hi Bernd, I can only speak to the sitaution of PHP 5.6 (in jessie) and 5.4 (in wheezy). The support for 5.6 is under the auspices of the LTS team, while the support for 5.4 is under the auspices of the Extended LTS (ELTS) team. On Tue, Oct 16, 2018 at 05:06:06PM +0200, Bernd Zeimetz wrote: > Hi, > > we (as in several customers and I) are wondering about the status > of php support in Debian. > > * According to http://php.net/supported-versions.php upstream > security support for 5.6 (jessie) and 7.0 (stretch) will be gone > soon. Is it possible to support these versions properly for our > users as long as there is security/LTS support for our releases? > I prepared the last three PHP 5.6 updates for jessie/LTS (5.6.36, 5.6.37, and 5.6.38) as well as the last two PHP 5.4 updates for wheezy/ELTS (5.4.45-0+deb7u15 and 5.4.45-0+deb7u16). My experience with those updates has been that new security-specific upstream releases (as the last few 5.6 releases have been) make it easy to identify specific security fixes and backport them even further (e.g., 5.6 to 5.4). My expectation would be that 7.1.x upstream security releases will continue the trend and that identifying the specific security fixes will continue to be straightforward. That said, I suspect that backporting security fixes may become more challenging with time because of significant differences between 5.6 and 7.1. Still, the LTS team supports various packages which no longer have official upstream security support. If the burden becomes too great, I expect that the team will evaluate the options and consider delcaring php5.6 in jessie end-of-life (as is done with some other packages which cannot feasibly be maintained in jessie). That is perhaps not the solution you were seeking. > * Lots of applications require php 7.1 or 7.2 these days. As > there is no official backport, the only option right now is > to use CentOS with SCLs. I know that there is > https://deb.sury.org - but prefer to trust stuff that was > built on Debian machines and is distributed/signed with a > key we trust. > I have encountered this same situation and have resorted to backporting packages from testing/unstable myself :-/ > > Will there be a proper solution for that soon? > I hope that there will be. Regards, -Roberto -- Roberto C. Sánchez
Re: News from devscripts
On Wed, Oct 03, 2018 at 05:42:16PM +0200, Xavier wrote: > Dear fellow developers, > > devscripts 2.18.5 has been released and brings some new uscan features > for developers: > - in git mode, uscan is now able to verify signed tags (#827065). >Example: > > version=4 > opts="mode=git,pgpmode=gittag" \ > https://github.com/rs/net-server-mail refs/tags/v([\d\.]+) debian > Wow! That is very nice. Thanks for the hard work. Regards, -Roberto -- Roberto C. Sánchez
Re: Looking for DD willing to sign my key around Berkeley/Oakland/San Francisco CA
On Wed, Aug 08, 2018 at 02:50:23PM -0700, Joseph Herlant wrote: > Hi, > > I'm currently maintaining a few packages and am looking for one or two > DD around Berkeley/Oakland/San Francisco in California that would be > willing to meet in order to sign my gpg key so I can go ahead and > start the DM process. > > I haven't seen any Debian event around here to meet more Debian people > but maybe I'm just not in the right list. > > Note: I'm not subscribed to the debian-devel mailing list for now, so > can you either keep me in CC or just PM me directly please? > https://wiki.debian.org/Keysigning/Offers#US There are three Debian Developers listed as offering to sign keys in San Francisco. That should get you started. Regards, -Roberto -- Roberto C. Sánchez
Re: Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: >On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern <[1]pk...@debian.org> wrote: > > This clearly writes the unencrypted tarball out to disk. > >It writes to `/dev/shm` which is not disk. That is not a valid assumption. You have no way of knowing the device behind /dev/shm. > It writes to a random >temporary directory, so that it cannot be guessed. It removes >the unencrypted content as soon as the operation is performed. Unless the operation is atomic there is a possibility it can be interrupted. >All this happens almost instantly, it never stays unencrypted >for a long time. Ibid. > It is almost the same thing as using a pipe (|). >What is wrong here? It is not the same thing and it is based on several invalid/flawed assumptions. > I have been using it for 2-3 years and >never had a problem. > That doesn't make it correct code. I spend most of my day in code bases authored by other people. I consistently find bugs that have been in production, unreported, for 10 or more years. A bug is still a bug when it is found and identified, even if it has never manifested itself in the real world. If you doubt that, please review the recent news surrounding the SPECTRE and MELTDOWN vulnerabilities. Regards, -Roberto -- Roberto C. Sánchez
Re: Bug#903880: Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 02:36:17PM +0200, Dashamir Hoxha wrote: >On Mon, Jul 16, 2018 at 2:21 PM Holger Levsen <[1]hol...@layer-acht.org> >wrote: > > On Sun, Jul 15, 2018 at 12:41:36PM +0200, Carsten Schoenert wrote: > > Hmm, do you have tried to validate your shell code? > > [2]https://www.shellcheck.net/ > > I just pasted > > [3]https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh > into > > and got quite a lot of problematic remarks. > > I've also done this now and must say/add "ouch": > >I have already answered this. Only one of the suggestions might be useful. >If everything was clean, according to shellcheck, this wouldn't mean at >all >that the program is safe and secure and takes care of all the cases. >I know what is going on in my program better than the mindless shellcheck. > I've been following this thread and it is very difficult for me to understand why constructive criticism from others is so difficult for you to accept. In general, the community of Debian Developers is very concerned with producing a high quality distribution and also with supporting free software development. The fact that some have taken the time and interest to critique your work is very positive. Yet, you choose to perceive their critiques as an attack and then launch your own counter-attack. I don't mean to lecture, but your responses to several of the messages in this thread indicate that you are likely a younger/junior developer. That is not intended to be disparraging, but rather I am trying to understand the reason for the way in which you have responded in this thread. In my own case, I know that my attitude in response to critique was much like yours, when I was still a young developer who thought he knew it all. Over the years, though, I have come to understand that I know far less than I thought I knew when I was younger. That is, the world of programming knowledge far larger than I originally understood it to be. Even now, as a very experienced and senior developer, I frequently seek the advice and review of colleagues whenever I make significant changes to existing code, write new code, etc. I can tell you that I am a far better and more productive developer as a result. Another thing which seems to indicate that you are not particularly mature as a developer is the manner in which you quickly dismiss the results of static analysis. Certainly, there are instances where the tools do not fully understand the meaning of your code and provide false alarms. However, I have come to realize that static analysis is right for more than it is wrong. So, I have adopted the position that unless I can clearly articulate a good reason why the static analysis is wrong and my approach is better (and defend that reason to other programmers more senior than myself), I defer to the tool and fix the code. I do this in several programming languages. Additionally, the argument that you make, "If everything was clean, according to shellcheck, this wouldn't mean at all that the program is safe and secure and takes care of all the cases," is totally invalid. The fact that the tool fails to catch everything is not justification to automatically reject the things that it does catch. If the tool is consistently wrong, contact the developer of the tool with a sample of your code that you think the tool is incorrectly flagging, and convince the tool developer (using a technical and supported argument) why the tool should be updated. Your discussion with the tool developer might reveal to you that there is a defect in your own code that you did not understand. I encourage you, for your own benefit to accept the criticism from myself and others in the spirit in which it was intended: to help you produce a better free software tool and to improve as a developer. Regards, -Roberto -- Roberto C. Sánchez
Re: Debian Policy 4.1.5.0 released
On Wed, Jul 04, 2018 at 10:58:12AM -0300, Samuel Henrique wrote: >Helllo, > > 9.1.1 > Update Debian's version of the Filesystem Hierarchy Standard from > 2.3 to 3.0, and update the list of exceptions. Only a tiny minority > of packages, if any, should be made buggy by this change. > >Where can i read debian's FHS 3.0? >I can only see 2.3 on [1]https://www.debian.org/doc/packaging-manuals/fhs/ It is kind of a pain to locate. Here is the link: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf Regards, -Roberto -- Roberto C. Sánchez
Re: Comma in Maintainer field
On Fri, Apr 20, 2018 at 12:46:51PM +0100, Ian Jackson wrote:
> Russ Allbery writes ("Re: Comma in Maintainer field"):
> > I am opposed to this on the grounds that there are two types of RFC822
> > parsers in the world: correct ones that will drive you insane if you
> > attempt to understand them, and incorrect ones. Nearly all of them are in
> > the latter bucket.
> >
> > Full RFC822 is incredibly complicated and way, way beyond any tool that we
> > currently use for Debian packages.
>
> That doesn't matter because we can use an existing one. Basically
> every programming language has a plausible library for this nowadays.
>
> Bear in mind that you do not need to parse the field to compare for
> equality, to search for it, or to send it email.
>
The implication of Russ' point is that there is only "one" way to be
compliant, but many ways to be non-compliant.
In my experience, various RFC822 parsing solutions tend to not produce
the same results as others.
> > I don't think this assumption is at all justified given the number of
> > tools in Debian that need to parse the Maintainer field for various
> > purposes (tracker.debian.org, dd-list, etc.).
>
> It's just a question of `import mail.headers' or whatever.
>
Which works if everyone uses the same version of only that one parser in
that language. If that were the case, then the consistent application
of the standard, even if the specific implementation is incorrect, makes
the point moot. However, not everybody is using the same language, or
even the same parser amongs all users of a given language.
I don't know if in practice the various implementations are "close
enough" for the purposes of the maintainer/uploader fields in the
control file. However, there is a high likelihood that enough of them
are different enough to be problematic from the perspective of a
heterogeneous tooling infrastructure.
Regards,
-Roberto
--
Roberto C. Sánchez
Re: Comma in Maintainer field (Was: problems in gjots2 and Debian)
On Thu, Apr 19, 2018 at 08:37:07AM +0200, Andreas Tille wrote: > On Wed, Apr 18, 2018 at 09:52:18PM +0500, Andrey Rahmatullin wrote: > > On Wed, Apr 18, 2018 at 04:00:51PM +0100, Ian Jackson wrote: > > > Instead, tools grew to tolerate commas here rather than treat them as > > > separators (because they would mishandle the erroneous packages). > > Is this the main problem with fixing the Policy? Does someone have a plan > > with this? > > I checked UDD for real cases: > > udd=# select distinct maintainer from packages where maintainer like '%,%' > order by maintainer; > maintainer > > -- > "Adam C. Powell, IV" <hazel...@debian.org> #547460 (and its blockers #401452 and #509935) might interesting to read if you have not already. Regards, -Roberto -- Roberto C. Sánchez
Re: libzstd_1.3.3+dfsg-2_multi.changes REJECTED
On Wed, Apr 18, 2018 at 12:52:18PM +0100, Chris Lamb wrote: > > Whilst this is not the most egregious example, I am not enjoying > this recent trend of almost-immediately escalating issues to our > mailing lists. > ... > > If one feels hurt or aggrievied by an interaction that might be > completely fair and legitimate (!) but the "junk" energy you feel > in the moment of dashing out a publical riposte has long-reaching > negative effects both on yourself and others that I am certain you > do not intend. > > I have, on occasion, written messages that I later (sometimes even immediately) regretted. What has worked well for me and helped prevent me from initiating or compounding situations like those you point out is this process: - Get upset over whatever the perceived offense is - Write the inevitably emotionally charged message (but DO NOT SEND) - Read the message back to myself, preferrably aloud - Delete the message - Turn down the "emotional dial" several notches and reconsider the situation, with a specific effort to have more charitable consideration of the actions of others involved - At this point, if a message still feels warranted, start from scratch and write a more courteous message that focuses on the specific techincal, procedural, or other issue, without resorting to emotional arguments or other inflammatory statements (this step may have to wait a day or more if the situation is especially volatile) I share it here in the case that others may find it helpful. This may be the sort of thing that is natural for some, but it was definitely not natural for me and I had to train myself to this. This approach certainly is not perfect, but I can personally attest that I have written and then subsequently deleted lots of messages that by any objective measure would have served to only worsen a situation. When I have failed to follow my own advice, I have without fail only made the situations in question worse. Regards, -Roberto -- Roberto C. Sánchez
Re: missing recommends are not RC severity
On Tue, Apr 17, 2018 at 09:21:31AM -0400, Jeremy Bicha wrote: > On Tue, Apr 17, 2018 at 9:16 AM, Holger Levsen <hol...@layer-acht.org> wrote: > > (not sure this makes sense as the practical impact is a normal bug, but > > Since I was CC'd on this email and I've filed several Serious bugs for > this issue, here is what I've been using lately: > > "It is my understanding that is a RC bug for package to recommend a > library that has been removed from Testing because recommended > packages won't be auto-removed on upgrade." > > That means users will have libraries installed that will not get any > security support. I think that's an RC issue. > Except that the reasoning breaks down when you consider that auto-removal of packages is a function of the package management front end and not of dpkg itself (which is responsible for validating the relationships between packages). There are plenty of available tools to identify system cruft, including packages that are no longer receiving security support and packages which do not exist in the current suite/release for which the system is configured. Regards, -Roberto -- Roberto C. Sánchez
Re: Systemd dependencies
On Mon, Feb 26, 2018 at 11:53:27AM +0100, Bastian Blank wrote: > On Mon, Feb 26, 2018 at 11:13:03AM +0100, Michael Meskes wrote: > > > However I really would start one step before. What exactly do you > > > think > > > a service dependency on "mail-transport-agent" does provide you? > > Actually it's the other way round. I need my program, clamsmtp, to > > start before postfix. I haven't checked with the other MTAs to be > > honest. So I guess I could try only adding postfix and see if somebody > > reports a problem. > > No, this is no reason to introduce such sequence points. You don't even > know that the MTA runs on the same system. > Unless it is designed to only interact with an MTA running on the same system. Regards, -Roberto -- Roberto C. Sánchez
Re: Extended Long Term Support for Wheezy
On Thu, Feb 22, 2018 at 07:31:23PM +0100, Didier 'OdyX' Raboud wrote:
> Le mardi, 20 février 2018, 16.07:03 h CET Raphael Hertzog a écrit :
> > ("super long-term maintenance", SLTS in their jargon)
>
> A small point, but I haven't seen anyone mention it yet: I would not use the
> 'slts' acronym, basically anywhere, as it is very close to the 'sluts' smear
> word.
>
You haven't seen anyone mention it because it is nonsense. The acronym
is also close to 'slats', 'slits', and 'slots', not to mention 'salts',
'stilts', and who knows how many other words in the English language.
If we are going to start applying this sort of logic to naming, then
there are plenty of other places (e.g., where actual vulgarities are
used in package names, where abreviations and/or acronyms create words
that are or can be perceived as offensive, etc.).
Regards,
-Roberto
--
Roberto C. Sánchez
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 09:42:28PM +0100, Michael Meskes wrote: > > Right, and that's why we were talking about stuff like flatpak that > bring the application with its dependencies, more or less like a > container. > Which happens to bring with an entirely different set of problems. That said, the problems are not really any different than the problems introduced by installing components with cpan or pip and then forgetting about them. Regards, -Roberto -- Roberto C. Sánchez
Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 10:16:56PM +0200, Adrian Bunk wrote: > On Mon, Feb 19, 2018 at 08:40:12PM +0100, Michael Meskes wrote: > >... > > > An example what "no security support" means in practice: > > > > I don't think anyone suggest "no security", but something like > > "security by upstream releases". > > How can you guarantee that to our users for buster until mid-2022? > > This only works when upstream provides an LTS branch covering the > lifetime of the Debian release. > > Debian already does "security by upstream releases" for Firefox, > and this clearly shows why this is problematic: Also PostgreSQL, formerly MySQL, OpenJDK, etc. Some go smoothly (I think PostgreSQL upstream is very good here), and some do not. Regards, -Roberto -- Roberto C. Sánchez
Re: What can Debian do to provide complex applications to its users?
On Fri, Feb 16, 2018 at 04:34:39PM +0100, Samuel Thibault wrote: > > When I see upstream java packages just stuffing .jar files without > indication of where they come from or even their licencing terms, it's > just unacceptable. > I see this as well and am quite frustrated by it. In the university class I teach, dependency management in our project is something that is quite important. Though, at that stage of life, the students usually lack the experience to appreciate why it is important. Regards, -Roberto -- Roberto C. Sánchez
Re: What can Debian do to provide complex applications to its users?
On Fri, Feb 16, 2018 at 04:11:29PM +0100, Raphael Hertzog wrote: > Hello everybody, > > the fact that I had to request the removal of dolibarr from Debian makes > me sad (see below for the reasons) and I believe that we should be able > to do better to provide complex applications to our end users. > > Dolibarr is not alone: > There was/is a similar issue with ownCloud/nextCloud. I would love to see something that allows for these complex packages (package ecosystems, really) to play nice with stock Debian. I am always hesitant to use unofficial upstream .deb packages unless I know that they have experienced Debian Developers involved in the packaging. There have been too many instances for me where such packages are of poor quality and end up causing more problems than they solve. My preferred method for applications like this is to install manually from tarballs and just ignore the unofficial .deb packages. Sadly, that is nearly always more work. The container approach is very interesting since many of the most complex packages would benefit greatly from being kept separate from the rest of the system for a multitude of reasons. Certainly security is one and dependency management is another (e.g., as in the Dolibarr example, where upstream only tests against certain versions of the dependencies which may not be available directly in Debian). Anyhow, these are just my thoughts. I would love to see some effort form around your proposal and would definitely get involved, time permitting. Regards, -Roberto -- Roberto C. Sánchez
Re: FTBFS with parallel make
On Fri, Jan 26, 2018 at 02:37:08PM +0500, Andrey Rahmatullin wrote: > On Fri, Jan 26, 2018 at 09:42:05AM +0100, Philipp Hahn wrote: > > we (Univention GmbH) rebuild packages (from Debian-Jessie or newer) > > using "-j8". > Is that a dpkg-buildpackage option? It's documented to fail on certain > packages, you need to use -J instead, and maintainers need to certify that > a package can be built in parallel by bumping the debhelper compat level > or passing appropriate flags to debhelper tools. > That is interesting. I build using gbp/cowbuilder and so I set these environment variables: DEB_BUILD_OPTIONS="parallel=`nproc`" DH_VERBOSE=1 I was not previously aware of the distinction between -j and -J for dpkg-buildpackage. However, looking at the dpkg-buildpackage man page there does not appear to be a DEB_BUILD_OPTIONS setting to trigger the use of -J in place of -j. At least, that is the case on stretch. Is there an easy way (preferrably via environment variables) to achieve that? Regards, -Roberto -- Roberto C. Sánchez
Bug#886238: Please introduce official nosystemd build profile
On Wed, Jan 03, 2018 at 02:25:03PM +0100, Marco d'Itri wrote: > On Jan 03, Andrew Shadura <and...@shadura.me> wrote: > > > Do we really need systemd-less builds? I'm not convinced this is > > something relevant to Debian. > Not at all. > This would be a lot of work for the benefit of a tiny audience: the > disturbed people who hate systemd so much that they cannot accept even > that libsystemd is installed on their computers. > - OR - > Not at all. > This would be a lot of work for the benefit of a tiny audience: the > disturbed people who hate [non-free] so much that they cannot accept even > that [any non-free software] is installed on their computers. I suspect that having the archive split into main/contrib/non-free involves a non-trivial amount of work. Yet Debian as a project, to serve its users and derivatives, undertakes the work. As has already been pointed out by others, if someone is interested in doing the work and it is not too invasive or disruptive to other parts of Debian, then it should be done. That said, I find that your characterization of someone not wanting systemd installed on their system as "disturbed" to itself be somewhat disturbing. You cannot possibly know what grounds someone might have for not wanting systemd, and to automatically and universally characterize that as "disturbed" implies a value judgment that runs counter both to the freeness and universailty that Debian as a project espouses. Regards, -Roberto -- Roberto C. Sánchez
Re: Debian Stretch new user report (vs Linux Mint)
On Fri, Dec 01, 2017 at 05:31:09PM +0100, Alf Gaida wrote: > > > Ian, thats dead easy - put the needed packages onto the iso and be done > with. The installer should have an option to opt-in contrib and/or > non-free. Done. Ok, that was the technical part. Which has the potential to make the installer non-distributable or not freely redistributable the same way as free packages. Even if the Debian project obtained the necessary permission/license to redistributed, it would certainly have restrictions and I suspect it would not likely be something that would autoatically transfer to other entities (think users copying/sharing installers or derivative distributions). The situation is more complex than your characterization. Regards, -Roberto
Re: [RFC] Cyrus SASL 2.1.26 experimental-unstable
On Fri, Jan 31, 2014 at 10:31:15AM -0200, Henrique de Moraes Holschuh wrote: On Thu, 30 Jan 2014, Roberto C. Sánchez wrote: That said, I am curious if there would be any opposition to an upload of cyrus-sasl2 2.1.26 into unstable. Aside from opposition, are there any other comments that anyone would like to offer in regard to this? Well, it has to go to unstable eventually, doesn't it? Might as well do it now unless it would cause trouble with some ongoing transition. That said, it is probably a good idea to check upstream's git repo for fixes to 2.1.26. I agree. The only question I have at this point is what special action needs to be taken with regard to the libsasl2-2 - libsasl2-3 transition that is introduced with the 2.1.25 - 2.1.26 update. For the time being, I am focusing on preparing only a 2.1.26 upload for unstable, but I will wait to upload it until the transition question is addressed. I apologize if this seems elementary, but I have not been responsible for any significant library transition yet. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [RFC] Cyrus SASL 2.1.26 experimental-unstable
On Fri, Jan 31, 2014 at 03:50:13PM +0100, Andreas Beckmann wrote: https://wiki.debian.org/Teams/ReleaseTeam/Transitions Thanks. I have filed a transition bug as required. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
[RFC] Cyrus SASL 2.1.26 experimental-unstable
[Note: I am sending this email to both debian-devel and pkg-cyrus-sasl2, as the pkg-cyrus-sasl2 list has low a population of subscribers, and changes to cyrus-sasl2 have the potential impact many other packages.] The cyrus-sasl2 package has seen better days, and I am trying to clean it up and get it into better shape. Thanks to the efforts of Ondřej Surý and Adam Conrad, the package has not been stagnant, but the bugs have still been accumulating. In June of 2013, version 2.1.26 was uploaded into experimental. It has now been there for 7 months, and in that time there have not been any bug reports filed that apply to only the package in experimental. I imagine that this more a result of lack of use, as opposed to absence of bugs. That said, I am curious if there would be any opposition to an upload of cyrus-sasl2 2.1.26 into unstable. Aside from opposition, are there any other comments that anyone would like to offer in regard to this? For the time being, I plan to continue my work on the 2.1.25 version that is currently in unstable (merging into the experimental version as appropriate). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to
On Fri, Jun 22, 2012 at 01:59:37PM +0200, Rudy Zijlstra wrote: Package: general Severity: important Tags: ipv6 let system run with IPv4 IPv6 routing for about 1 month IPv6 routing will start to fail IPv4 routing becomes slow and unpredictable no obvious causes visible in the system. top and friends do not show a cpu hog a reboot will bring the system back to normal behaviour. Could this be something to do with connection tracking? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system
On Sat, Dec 17, 2011 at 06:08:35PM -0430, Luis Alejandro Martínez Faneyth wrote:
On 17/12/11 16:19, Sune Vuorela wrote:
$sel_q = SELECT * FROM NewUser
. WHERE mail=' . $mail . '
. AND uid=' . $uid . '
. AND token=' . $token . '
. ORDER BY token DESC LIMIT 0,1;
Thanks for having a look :)
Well, i perform a very strict validation before that query is made.
Lines 20 - 54:
http://code.google.com/p/aguilas/source/browse/NewUserDo.php#20
http://code.google.com/p/aguilas/source/browse/NewUserDo.php#54
You are still scared?
I would be. Bind variables exist for a reason. Aside from that, your
validation of email addresses is wrong:
// Invalid e-mail
} elseif (preg_match(/\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*/, $mail) ==
0) {
First off, there is nothing in the RFC that says that the email address
must start with a letter, which your regex requires. In addition to
that, you do not allow other allowed special characters:
!#$%'*/=?^_`{|}~(),:;@[\]
You also don't properly check for consecutive dots, so I could pass the
email a@foo.com and it pass your check, and still be wrong.
What you have done is reinvent the wheel, and badly at that.
If it were up to me, I would reject this package based on that one line
of code alone.
CODE IS POETRY
I find it terribly ironic that you have that satement in your email
signature.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111217225432.ga27...@connexer.com
Re: Bug#652464: ITP: aguilas -- A web-based LDAP user management system
On Sat, Dec 17, 2011 at 07:02:35PM -0430, Luis Alejandro Martínez Faneyth wrote: On 17/12/11 18:24, Roberto C. Sánchez wrote: What you have done is reinvent the wheel, and badly at that. I coudn't find any other user friendly interface to manage user accounts from an LDAP. I should have been more clear. I was referring to the fact that there are lots of proven ways to validate email addresses in PHP. In fact, you don't even need any external library, you can just use filter_var(): http://php.net/manual/en/filter.examples.validation.php Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: 0-day NMUs for RC bugs without activity for 7 days?
On Fri, May 06, 2011 at 11:14:55PM +0200, Lucas Nussbaum wrote: - Doing an NMU without trying to contact the maintainer beforehand could be considered an aggressive behaviour, or a way to punish the maintainer for not addressing bugs as fast as one would like. We are trying hard to fight the feeling that NMUs are an aggression, this could be counter-productive. So, my experience with #624819 was basically this. The bug was reported, followed by an NMU upload about 45 minutes after the bug was initially reported. Please don't misunderstand. I appreciate that the submitter was proactive. However, emailing the patch first and giving me a few days would have been nice. Since the NMUer made changes directly to the source files, I have to back out the patch and convert it over to quilt (I use quilt on all my packages). So, his helpfulness actually created more work. Another thing to note is that while the NMU was uploaded to DELAYED/2, the upload was actually ACCEPTed about 24 hours after the upload. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Source code
On Tue, Jan 04, 2011 at 08:55:41PM +0100, Olaf van der Spek wrote: On Tue, Jan 4, 2011 at 8:45 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Because lots of programs expect something like fd = open(/tmp/foo, O_WRONLY|O_CREAT|O_EXCL); unlink(/tmp/foo); write(fd, data, 4); to succeed. This is how Unix filesystem semantics work and pretty much always have. POSIX allows unlink(2) to return EBUSY, but that's not at all Unixy. The only case I can see for EBUSY is what NetBSD and OpenBSD do: restrict unlinking a mount point. (This is also the only case for EBUSY on Solaris, Ultrix, and HP-UX.) unlink will probably return an error, but since that's not checked, that snippet will succeed. WRONLY seems weird, what's the purpose of a snippet like this? There are several reasons to do something like that. One is that in the event of the process (or even entire OS) crashing, cleanup of the disk space is essentially automatic, because once no open file descriptors reference, the OS reclaims it. Another reason to do something like that is to give you a more secure temporary file. By adding mktemp() (or something similar) into the example Brian gave, you can defend against attacks that depend on file name collisions. By quickly unlinking, the file will no longer appear in directory listings, making exploits of the data written to the file more challenging (not impossible, just more challenging). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#601977: cyrus-sasl2-heimdal-dbg: file conflict during upgrade from lenny
On Sun, Oct 31, 2010 at 03:42:29PM +0100, Lucas Nussbaum wrote: Package: cyrus-sasl2-heimdal-dbg Version: 2.1.23.dfsg1-6 Severity: serious Hi, Installing cyrus-sasl2-heimdal-dbg in a lenny chroot, then upgrading to squeeze, causes: Preparing to replace cyrus-sasl2-heimdal-dbg 2.1.22.dfsg1-23+lenny1 (using .../cyrus-sasl2-heimdal-dbg_2.1.23.dfsg1-6_amd64.deb) ... Unpacking replacement cyrus-sasl2-heimdal-dbg ... Preparing to replace cyrus-sasl2-dbg 2.1.22.dfsg1-23+lenny1 (using .../cyrus-sasl2-dbg_2.1.23.dfsg1-6_amd64.deb) ... Unpacking replacement cyrus-sasl2-dbg ... dpkg: error processing /var/cache/apt/archives/cyrus-sasl2-dbg_2.1.23.dfsg1-6_amd64.deb (--unpack): trying to overwrite '/usr/lib/debug/usr/lib/sasl2/libgssapiv2.so.2.0.23', which is also in package cyrus-sasl2-heimdal-dbg 2.1.23.dfsg1-6 configured to not write apport reports dpkg-deb: subprocess paste killed by signal (Broken pipe) I'd be interested to know if anyone has a recommendation on how to handle this. The two packages in question are -dbg packages that are created by dh_strip, excerpted from debian/rules below: dh_strip -s -psasl2-bin -plibsasl2-2 -plibsasl2-modules -plibsasl2-modules-ldap -plibsasl2-modules-otp -plibsasl2-modules-sql -plibsasl2-modules-gssapi-mit -plibsasl2-dev -Nlibsasl2-modules-gssapi-heimdal --dbg-package=cyrus-sasl2-dbg dh_strip -s -plibsasl2-modules-gssapi-heimdal -Nsasl2-bin -Nlibsasl2-2 -Nlibsasl2-modules -Nlibsasl2-modules-ldap -Nlibsasl2-modules-otp -Nlibsasl2-modules-sql -Nlibsasl2-modules-gssapi-mit -Nlibsasl2-dev --dbg-package=cyrus-sasl2-heimdal-dbg Both packages need to be able to be installed together, so my question centers around whehter it is OK to put a diversion in place so that cyrus-sasl2-heimdal-dbg diverts the file. What does everyone think? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: backports.org moved to backports.debian.org
On Sun, Sep 05, 2010 at 11:51:12PM +0200, Joerg Jaspert wrote: You should also update your dput/dupload config, uploading to backports-master.debian.org instead of www.backports.org For the next days uploads to the old location will be forwarded, but at some point this will stop, so update your config. :) This appears in my /etc/dput.cf: [backports.org] fqdn= www.backports.org incoming= / method = ftp login = anonymous I don't recall putting it there, so I believe that it ships that way. Is there a way that the dput package in Debian be updated to point to the new location? It would be quite annoying, IMHO, to have it pointing at the wrong place for the life of Squeeze. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Let's write a system admin friendly mail server packaging system
On Wed, May 26, 2010 at 06:42:50PM +0200, Michael Banck wrote: On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. That is true. However, it must be balanced with making the software different than it is on every other platform. I'm not saying that it cannot be done. Rather, there needs be a discussion as to whether that is something that Debian wants to do. It is not as simple as just patching a high profile package like postfix. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Dual init scripts (or two init scripts in one package)
On Fri, May 07, 2010 at 07:35:02PM -0700, Russ Allbery wrote: Roberto C. Sánchez robe...@connexer.com writes: Greetings. I am curious as to how the scenario described in the below message would work in Debian. That is, can one package install two init scripts? Sure. A package can install as many init scripts as it wants and needs. So, currently the shorewall package ships debian/shorewall.init, which is accompanied by the following debian/rules entry: dh_installinit --no-start -ustart 40 S . stop 89 0 6 . If I read the dh_installinit manpage correctly, then I can ship: debian/shorewall.shorewall-prenet.init debian/shorewall.shorewall-postnet.init Then in debian/rules I would have: dh_installinit --no-start --name=shorewall-prenet -ustart 35 S . stop 89 0 6 . dh_installinit --no-start --name=shorewall-postnet -ustart 40 S . stop 89 0 6 . The idea is to have one init script that runs before S40networking and another that runs after. Does this seem right? I will still have to figure out the right start and stop values, but I just want to make sure I generally have the mechanics right. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Dual init scripts (or two init scripts in one package)
Greetings. I am curious as to how the scenario described in the below message would work in Debian. That is, can one package install two init scripts? Regards, -Roberto - Forwarded message from Tom Eastep teas...@shorewall.net - Date: Tue, 04 May 2010 12:28:47 -0700 Subject: Dual init scripts From: Tom Eastep teas...@shorewall.net To: Roberto C. Sanchez robe...@connexer.com Hi Roberto, The Gentoo folks have an issue with the way that Shorewall is normally started; namely, we supply init scripts that start the firewall after networking has started. This is an issue in that there is a window after networking starts but before Shorewall starts when the firewall is wide open. SuSEFirewall manages this issue by having multiple init scripts; one that runs prior to networking startup and one that runs after. That is what I'm planning to do with Shorewall in 4.4.10. So the question is, can a single 'shorewall' package (for example), provide both scripts or do I need four additional packages, the only purpose of which would be to provide 4 additional init scripts. Thanks, -Tom -- Tom Eastep\ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \ - End forwarded message - -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: dpkg-deb temporary storage directory
On Sat, Mar 06, 2010 at 05:14:48PM -0500, Adam C Powell IV wrote: On Sat, 2010-03-06 at 18:15 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (06/03/2010): How can I change the temporary directory where it builds the tarballs? I don't see anything in the manpage or dpkg-deb --help output. (Untested) It probably honours TMP/TMPDIR environment variables. Ah yes, a search for dpkg-deb TMPDIR turns up bug 247086 where someone asked to include this in the documentation. The reply: but it's so obvious, no need to include it. Version 1.10.22 claimed to fix it, but only fixed one part of the bug, the TMPDIR issue remained. I've been a DD for ten years and didn't think of it, so I can't agree about the obviousness... I think I'll open a new bug. This makes me wonder if it would be a good idea to include something in policy about applications respecting TMP/TMPDIR. I have run across several applications in Debian at various times that do not really support TMP and TMPDIR to the degree that one would expect. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
-fPIC, libraries, and overriding a lintian error
In the process of preparing a new oprofile package with a fix for #537744, I have encountered a peculiar situation. The fix recommended by the submitter is to link statically against /usr/lib/libbfd.a, rather than dynaimcally against -lbfd. However, doing that results in the following lintian error: E: oprofile: shlib-with-non-pic-code usr/lib/oprofile/libopagent.so.1.0.0 Since the library is installed under /usr/lib/oprofile, I am wondering if the following statement from policy applies: Shared object files (often .so files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the /usr/lib directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped. [0] Does that mean that I am permitted to override the lintian error? Regards, -Roberto [0] http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: -fPIC, libraries, and overriding a lintian error
On Tue, Nov 24, 2009 at 08:43:12PM -0500, Roberto C. Sánchez wrote: Does that mean that I am permitted to override the lintian error? Please disregard. It turns out that the proposed fix causes a FTBFS on amd64, which is not acceptable. Overriding the lintian error will clearly not help that. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Moving binary packages between source packages, and closing bugs
On Sat, Oct 03, 2009 at 04:54:54PM +0200, Frank Küster wrote: Hi, assume a binary package A has been built from source package X, but a new upload of source packages X and Y moves it, and it is now built from Y. Now, will the changes file of Y properly close the bug in A? In other words, will the BTS be aware of the change in source package before the changes file is processed? In my experience, the answer to this is yes. In my case, #538907 was reported against shorewall-perl (built from the shorewall-perl source package). Upstream, the Shorewall project reorganized its packages and shorewall-perl became a dummy binary package built from the shorewall source package. The upload that closed that bug was after the switch of the binary package, and the bug was in fact properly closed. To make things even more complicated, the first upload of the new packages would be to experimental... This I do not know about. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Seeking advice on packaging of pion-net
I am packaging pion-net [0], which is currently at version 2.1.8. Once built, the SONAMEs of the two shared library packages are: libpion-net-2.1.8.so libpion-common-2.1.8.so According to the Debian Library Packaging Guide [1], with SONAMEs like that, the packages should be named libpion-net-2.1.8 and libpion-common-2.1.8. However, I am not certain what the best way to handle this is. I am currently thinkging of naming the packages like this: Source: pion-net Binary: libpion-net-dev, libpion-net-2.1.8, libpion-common-2.1.8, libpion-net-2.1.8-dbg, libpion-common-2.1.8-dbg, libpion-net-doc The problem, as I see it, with this arrangement is, that when a new upstream released, like 2.1.9, then four of the package names will change, resulting in the need for the new upstream to pass NEW processing. I don't currently plan to package and reverse dependencies. However, that is not to say that someone else will not in the future. I have looked at how some other packages handle it (e.g., boost), but they version even the -dev package and source package, so that each new upstream release results in a new source package. I'm not sure if that approach would work or is appropriate for this package. Any advice/insights on this would be appreciated. Regards, -Roberto [0] http://bugs.debian.org/547607 [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Moving init script from one package to another
As part of the shorewall package reorganization, the /etc/init.d/shorewall init script (and the symlinks to it) has moved from the shorewall-common package to the shorewall package. However, after the upgrade of shorewall-common (which has become a dummy package), and the installation of the new shorewall binary package, it is not possible to purge the shorewall-common package. The error I get is this: Purging configuration files for shorewall-common ... update-rc.d: /etc/init.d/shorewall exists during rc.d purge (use -f to force) dpkg: error processing shorewall-common (--remove): Is there some magic I can put into a prerm/postrm script that will handle that? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Resigning from Debian
On Mon, Jul 06, 2009 at 05:12:44PM +0200, Alexis Sukrieh wrote: electricsheep[1] deserves a prioritary adoption: a major upstream version has been released and Debian's is now deprecated. I'd like to adopt electricsheep. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Requesting opinions on #515215 (rename sparsehash - libsparsehash-dev)
The submitter of #515215 is requesting that the sparsehash binary package be renamed to libsparsehash-dev. However, the package only contains header files and documentation. It is not a development library in the traditional sense. My thinking is that the package name should not be changed. I am preparing a new upstream release right now for upload, so this would be a good time to make the change if people think it is necessary/desirable. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#531221: okular: Arbitrarily enforces DRM
On Sat, May 30, 2009 at 09:40:20PM -0500, John Goerzen wrote: I would go so far as to propose patching it out of Okular entirely. Debian should not be a tool to support software restrictions like this. If Debian should not be a tool to support software restrictions like this, then against which package should I file a bug to have all unix user/group permissions ignored? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#531221: okular: Arbitrarily enforces DRM
On Sun, May 31, 2009 at 12:25:05PM +0200, Josselin Mouette wrote: Le dimanche 31 mai 2009 à 06:00 -0400, Roberto C. Sánchez a écrit : If Debian should not be a tool to support software restrictions like this, then against which package should I file a bug to have all unix user/group permissions ignored? debian-devel is not the right place to ask for the basic knowledge on what is an authorization system (which would be necessary for you to understand why DRM is not an authorization system). DRM is a form of access control. User and group permissions are also a form of access control. Disagreeing with the philosophy behind one or the other does not change its technical nature. Also, I do know what an authorization system is, which is why it is clear (at least to me) that DRM is just an authorization system. Which definition do you have in mind where DRM is not an authorization system? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#531221: okular: Arbitrarily enforces DRM
On Sun, May 31, 2009 at 12:11:07PM +0100, Enrico Zini wrote: Allow me to use your analogy[1] to look at an example of a behaviour that I consider sane: $ echo ciao /tmp/foo $ chmod -w /tmp/foo $ vim /tmp/foo :w - E45: 'readonly' option is set (add ! to override) :w! - /tmp/foo 2L, 11C written Here is behavior that I consider to be equally sane: $ su - Password: # echo ciao /tmp/foo # chmod -w /tmp/foo # exit logout $ vim /tmp/foo :w - E45: 'readonly' option is set (add ! to override) :w! - /tmp/foo E212: Can't open file for writing This hints at the idea that those permissions that the user can change are to be considered advisory, and those that the user cannot change are to be considered mandatory. On this we are in agreement. We have also long come to the conclusion that enforcing laws (be they questionable or not) is something that is the responsibility of the users (or their sysadmins), and not of software alone. So far we are talking about the technical measures themselves. If you talk about potential penalties for circumvention, then that might have to do with enforcing laws. In reality, what I am having trouble with is, how these two scenarios are different: 1. Someone produces a PDF with certain DRM restrictions. The user decides that he does not like the restrictions and so looks to circumvent them. 2. A user or sysadmin produces a file and removes certain access (read and/or write) for other users. The user decides that he does not like the restrictions and so looks to circumvent them. If people are arguing that Debian should assist the user in the first case, then why is the same not also true in the second case? I agree with Sune that such disagreements are best handled between the user and the producer of the file. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: dash as default /bin/sh and bashisms-free archive RGs
On Sun, Apr 12, 2009 at 09:35:37PM +0200, Marco d'Itri wrote:
* Bashisms-free archive
This is useless. You are basically proposing to remove every usage of
local and a few other directives for no good reason but at a huge cost.
Policy specifically states that use of local is permitted [0]:
* local to create a scoped variable must be supported, including
listing multiple variables in a single local command and assigning
a value to a variable at the same time as localizing it. local may
or may not preserve the variable value from an outer scope if no
assignment is present. Uses such as:
fname () {
local a b c=delta d
# ... use a, b, c, d ...
}
must be supported and must set the value of c to delta.
Regards,
-Roberto
[0] http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: [luabind] Naming library with proper SONAME
On Tue, Mar 10, 2009 at 06:30:19PM -0400, Roberto C. Sánchez wrote: [My apologies in advance for the cross-posting.] On Tue, Mar 10, 2009 at 10:42:36AM +0100, Daniel Wallin wrote: Roberto C. Sánchez wrote: So, I've been trying to build the Debian package with the latest from the 0.8 branch on github. It seems like the SONAME thing is not completely resolved. I am seeing this after building: robe...@miami:~/src/luabind-upstream$ objdump -p ./bin/gcc-4.3.2/debug/libluabindd.so.0.8.0 |grep SONAME SONAME libluabindd.so.0.8.0 Yes, that's the expected result, isn't it? The reasoning was that it's too difficult to have ABI-compatibility, so we just use the complete version number as the SONAME. bjam install will create the unversioned symlink. I am curious as to what people generally think of how the libluabind SONAME will be going forward. I know that certain packages (like libssl) have the complete version in the SONAME, but I can't imagine that this is a really good idea. Is this a showstopper for having libluabind in Debian, or just for a stable release? Is this discouraged, but otherwise permissible? I have done some further digging and found a blog post [0] that explains the issues with templated C++ code and ABI. What it boils down to is that if templates are used in a library, it really cannot have an ABI. I also found a bug report [1] against gecode that was closed with a similar explanation. The solution implemented by the libgecode maintainer in Debian was to increment the SONAME for each release. That said, I think that the best solution is to have a different SONAME for each release, based on the use of template code. Since it is currently being set as the library's release version, that is probably the way to go. Additionally, I guess it is important for me (as the person packaging the .deb) to know what the planned release frequency is going to be. The reason is that each SONAME change will result in a new package being created and in a library transition (should libluabind gain any reverse dependencies). Each time that happens, the package will have to pass NEW processing. Regards, -Roberto [0] http://julipedia.blogspot.com/2005/10/c-templates-and-abi.html [1] http://www.gecode.org/bugzilla/show_bug.cgi?id=24 -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [luabind] Naming library with proper SONAME
On Thu, Mar 12, 2009 at 10:18:59PM +0100, Adeodato Simó wrote: * Roberto C. Sánchez [Tue, 10 Mar 2009 18:30:19 -0400]: I am curious as to what people generally think of how the libluabind SONAME will be going forward. I know that certain packages (like libssl) have the complete version in the SONAME, but I can't imagine that this is a really good idea. Is this a showstopper for having libluabind in Debian, or just for a stable release? Is this discouraged, but otherwise permissible? It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Currently, none of the luabind packages have reverse dependencies (except for stuff like libluabind-dbg depending on libluabind0). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [luabind] Naming library with proper SONAME
On Thu, Mar 12, 2009 at 10:39:37PM +0100, Adeodato Simó wrote: * Roberto C. Sánchez [Thu, 12 Mar 2009 17:34:20 -0400]: It’s certainly not desirable. Do you have an estimation of how many reverse dependencies libluabind will have? Goswin’s remark about API compatibility is also an important one. Currently, none of the luabind packages have reverse dependencies (except for stuff like libluabind-dbg depending on libluabind0). Yes, but I asked about an *estimation* of how many there *will* be. Good question. I do not know, but I would be surprised if it were more than a handful (10 at most). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bug#518869: ITP: shorewall6 -- Shoreline Firewall (IPv6 version), netfilter configurator
On Mon, Mar 09, 2009 at 08:38:23AM +0100, Stefano Zacchiroli wrote: On Sun, Mar 08, 2009 at 08:34:23PM -0400, Roberto C. Sanchez wrote: Description : Shoreline Firewall (IPv6 version), netfilter configurator Uh? Can you please explain? Even though I'm not following the upstream evolution I'm a user of the shorewall package, which has IPv6 support even though disabled by default. Why we now need a separate package now? Upstream releases now the following packages for 4.2.x: shorewall-common shorewall-docs shorewall-lite shorewall-perl shorewall-shell shorewall6 shorewall6-lite shorewall6 depends upon shorewall-perl (and consequently shorewall-common) in order to work properly. It is a different rules engine/compiler that handles IPv6 packet filtering. It was implemented separately because it is in many ways much simpler than IPv4 packet filter (e.g., there is no NAT in IPv6 and IPsec is part of the spec instead of requiring encapsulation). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [Suggestion] Reject Mail to ITP Bug
On Tue, Aug 26, 2008 at 04:10:38PM +0200, Joerg Jaspert wrote: It will be very helpful if Rejection is also mailed to ITP (where it apply) so, that anyone can look at actual reason and fix problem (packaging, contacting upstream for license issues etc). Fine. If you - get a uniform (and not too hard) way to know which ITP(s) belong to the package we just process, if any, That can be easily determined by looking in the .changes for the closes field. If more than one, you can check to see which has ITP in the title. If there is no closes, then assume that there is no ITP and that's it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
