Re: Is running dpkg-buildpackage manually from the command line forbidden?
On Fri, Jan 17, 2020 at 03:02:06AM +, Paul Wise wrote: > Personally, I think there is value in Daniel's work on bootstrapping > Debian from other operating systems and Helmut's work on bootstrapping > Debian from existing Debian architectures. Both are important projects > and we need Debian and FLOSS in general to be more bootstrappable than > it is now [...] indeed! > At some point I'd even like to see Debian > bootstrapped from whatever comes out of the the Bootstrappable Builds > project: > > https://bootstrappable.org/ Vagrant (cc:ed) was working on this at the last reproducible builds summit. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: https://tracker.debian.org/pkg/dballe
> "Paul" == Paul Wise writes: >> If we throw away binaries by default, I do believe we need a mechanism >> for maintainers to signal that this is a bootstrap upload. Paul> My proposed mechanism is that when the buildds cannot do the job due to Paul> need for a bootstrap process, the maintainer should do a binary-only Paul> build (using whatever ugly hacks are needed), dak should import that Paul> into a special part of the archive for bootstrapping packages that need Paul> that and then tell the buildds to do a new non-bootstrap build but Paul> using the bootstrap archive. I don't care about the mechanism. What I care is that we not go through a period where invoking the mechanism involves adding a round trip with ftpmaster, with waiting for an upload to be accepted, or with the release team, or otherwise delay the process. We've heard again and again from maintainers that the more they can accomplish within a single unit of attention span, the better. Every time you have to come back later after some process has done its thing, it makes maintaining stuff more frustrating, less rewarding, and more difficult. Many have argued that the current dance with new--where you have to upload binaries for new, but then later upload without binaries for testing--is one step too far in that direction. If those people are right, we should have waited until we could throw away binaries from new before requiring built-on-buildd for testing. I understand the politics are complex and that the release team's decision may have given motivation to push for patches to throw away binaries from new. Based on the discussion of maintainer motivations, I think going through a similar period where bootstrap uploads got harder--even if it eventually got fixed--would be a mistake and would not value the time of our maintainers. So, in order to value the time of our maintainers, I think a change to throw away binaries from uploads that don't hit new needs to block on a way of handling bootstrap builds. (Ideally that would be part of a patch to throw away binaries from uploads to new, but the trade offs are more complex for that situation.)
Re: https://tracker.debian.org/pkg/dballe
On Sat, Jan 18, 2020 at 08:40:29AM +0800, Paul Wise wrote: > On Fri, 2020-01-17 at 03:45 -0500, Sam Hartman wrote: > > Bootstrap uploads of compilers etc are actually more common than I > > thought before I started following debian-release. > The important part of my statement is that they are special, rather > than that they are rare. this. and on top of this, these uploads only need to be done by a handful of people, not all >1000 uploaders we have in the keyring. > > They are common enough that requiring interactions from ftpmaster and/or > > release team would make being a developer of such packages suck > > significantly more. > Hmm, OK. I can't recall seeing any recently on debian-release. in the last half year I do recall rustc... -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: https://tracker.debian.org/pkg/dballe
On Sat, 2020-01-18 at 08:25 -0500, Sam Hartman wrote: > I don't care about the mechanism. > What I care is that we not go through a period where invoking the > mechanism involves adding a round trip with ftpmaster, with waiting for > an upload to be accepted, or with the release team, or otherwise delay > the process. The proposed mechanism does not involve anyone other than the maintainer and doesn't substantially change existing workflows. The only difference is that for bootstrap builds instead of doing a source-and-binary upload, they do a source-only upload like they do for non-bootstrap builds and then afterwards a binary-only upload (which would normally be done by the buildds for non-bootstrap builds). Personally I don't think that is a significant burden, but I assume a .changes file option could be added for folks who think it is an issue. I won't be doing any work on this and this will be my last email on it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#949198: (no subject)
Control: retitle -1 ITP: parsero -- Audit tool for robots.txt of a site On Vi, 17 ian 20, 21:37:48, Thiago Andrade Marques wrote: > Subject: ITP: parsero -- Audit tool for robots.txt of a site > Package: wnpp > Owner: Thiago Andrade Marques > Severity: wishlist > > * Package name: parsero > Version : 0.0+git20140929.e5b585a > Upstream Author : Javier Nieto > * URL : https://github.com/behindthefirewalls/Parsero/ > * License : (GPL-2+ > Programming Lang: Python3 > Description : Audit tool for robots.txt of a site > > Parsero reads the Robots.txt file of a web server and looks at the Disallow > entries. > The Disallow entries tell the search engines what directories or files hosted > on a > web server must not be indexed. For example, "Disallow: /portal/login" means > that the > content on www.example.com/portal/login it's not allowed to be indexed by > crawlers > like Google, Bing, Yahoo... This is the way the administrator have to not > share > sensitive or private information with the search engines. > -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
MiniDebConf Maceió (Brazil) March 25-28, 2020
Hi, Did you come to DebConf19 last year? It's time you come back, but now to know the Northeast and its beautiful beaches! What? you didn't come?? So, it's your new opportunity to visit Brazil :-) The brazilian community of Debian developers and users invites you to the MiniDebConf in Maceió, Brazil. MiniDebConf will take place from March 27th to 28th at Federal University of Alagoas, and it will be preceded by a MiniDebCamp from March 25th to 26th at the same location. Maceio is known as "paradise of waters", is considered as the "Brazilian Caribbean" due to its natural beauties that attract tourists from around the world. CfP is open until February 15th. Come join us the 4th MiniDebConf edition in Brazil, and the 1st in Northeast! https://maceio2020.debian.net -- Paulo Henrique de Lima Santana (phls) Curitiba - Brasil Debian Developer Diretor do Instituto para Conservação de Tecnologias Livres Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450
Bug#949250: ITP: libyaml-pp-perl -- pure-perl YAML framework
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libyaml-pp-perl Version : 0.018 Upstream Author : Tina M??ller * URL : https://metacpan.org/release/YAML-PP * License : Artistic or GPL-1+ Programming Lang: Perl Description : pure-perl YAML framework YAML::PP is a modern, modular YAML processor. It aims to support YAML 1.2 and YAML 1.1. YAML is a serialization language. The YAML input is called "YAML Stream". A stream consists of one or more "Documents", separated by a line with a document start marker '---'. A document optionally ends with the document end marker '...'. This allows one to process of continuous streams additionally to a fixed input file or string. The YAML::PP frontend will currently load all documents, and return only the last if called with scalar context. The YAML backend is implemented in a modular way that allows one to add custom handling of YAML tags, perl objects and data types. The inner API is not yet stable. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Re: MiniDebConf Maceió (Brazil) March 25-28, 2020
On Sat, Jan 18, 2020 at 7:15 PM Paulo Henrique de Lima Santana wrote: > The brazilian community of Debian developers and users invites you to > the MiniDebConf in Maceió, Brazil. MiniDebConf will take place from > March 27th to 28th at Federal University of Alagoas, and it will be > preceded by a MiniDebCamp from March 25th to 26th at the same location. You might also want to send info about it to these locations: https://lists.debian.org/debian-publicity/ https://lists.debian.org/debian-events-ha/ https://lwn.net/Calendar/ -- bye, pabs https://wiki.debian.org/PaulWise
