Bug#935393: ITP: ruby-asciidoctor-include-ext -- Asciidoctor's standard include::[] processor reimplemented as an extension
Package: wnpp Severity: wishlist Owner: Sruthi Chandran X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruby-asciidoctor-include-ext Version : 0.3.1 Upstream Author : Jakub Jirutka * URL : https://github.com/jirutka/asciidoctor-include-ext * License : Expat Description : Asciidoctor's standard include::[] processor reimplemented as an extension This is a reimplementation of the Asciidoctor's built-in (pre)processor for the include::[] directive in extensible and more clean way. It provides the same features, but you can easily adjust it or extend for your needs. For example, you can change how it loads included files or add another ways how to select portions of the document to include. signature.asc Description: OpenPGP digital signature
Bug#935421: ITP: jeepney -- pure Python D-Bus protocol client
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: jeepney Version : 0.4.1 Upstream Author : Thomas Kluyver * URL : https://gitlab.com/takluyver/jeepney * License : MIT Programming Lang: Python Description : pure Python D-Bus protocol client This is a low-level, pure Python D-Bus protocol client. It has an I/O-free core, and integration modules for different event loops. D-Bus is an inter-process communication system, mainly used in Linux. I am going to maintain this package under DPMT umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote: > > so i hope that list gives a bit more context as to how serious the > consequences of dropping 32 bit support really is. I very much doubt we are any where near "dropping 32-bit support". There's a lot of "all or nothing thinking" in your argumentation style. As Sam has said multiple times, what's much more likely is that the set of packages that can't be built on native packages on 32-bit platforms will grow over time. The question is when will that actually *matter*? There are many of these packages which no one would want to run on a 32-bit platform, especially if we're focusing on the embedded use case. At least initially, the simplest way of dealing with the problem is that maintainers will simply not build their package on 32-bit platforms. If it's for some "large matrix multiplication" package, it might not matter. And if there is someone for which it will matter, then they can contribute the work to make that package build successfully on 32-bit platforms. Perhaps that will get done via improving the toolchains, or by changing the package in question so it is more friendly to linkers running in limited address space. When do we get to the point where /bin/ld is going to fail core critical packages like, say, util-linux? My claim is that it is *far* in the distant future. If you have hard data showing that this date is coming in the near future, please share it. Regards, - Ted
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Thursday, August 22, 2019, Theodore Y. Ts'o wrote: > On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton > wrote: > > > > so i hope that list gives a bit more context as to how serious the > > consequences of dropping 32 bit support really is. > > I very much doubt we are any where near "dropping 32-bit support". Theo you have not rear the context. Sam specifically asked a question and I answered it. > There's a lot of "all or nothing thinking" in your argumentation > style. That would be incorrect, Theo. Having read the Debian Conduct Document, please also read it. Also please review the context properly. As Sam has said multiple times, what's much more likely is that the > set of packages that can't be built on native packages on 32-bit > platforms will grow over time. Yes. Everyone is aware of that. It is why the conversation exists. Why did you assume that I was not aware of this? The question is when will that > actually *matter*? There are many of these packages which no one > would want to run on a 32-bit platform, especially if we're focusing > on the embedded use case. That would also be specifically missing the point, which I have mentioned at least twice, namely that 32 bit Dual and Quad Core 1ghz and above systems are perfectly capable of running a full desktop environment. Obvioudly you don't run video editing or other computationally heavy tasks on them, however many such so-called "embedded" claased processors were specifically designed for Android tablets or IPTV and so consequently not only are 3D capable, they also have 1080p video playback. So again: these are NOT pathetic little SINGLE CORE 8 to 10 year old processors with 256 to 512MB of RAM (OMAP3 series, Allwinner A10), these are 2 to 5 year old DUAL to QUAD Core systems, 2 to 4 GB RAM, 1 to 1.5ghz and perfectly capable of booting to a full Desktop OS in 25 seconds or less. The last time that we spoke, Theo, some time around 2003 you informed me that you were doing so very deliberately "to show everyone how stupid I was". It was on the linux kernel lists. It was also very shockingly unkind. I can see some signs that you are tryint to be deliberately confrontational and I do not like it. As the Debian lists are covered by the Debian Conduct document, please read it and review the talk that was given in Taipei (it had a panel of 5 people including Steve McIntyre, if someone remembers it please do kindly post a link). Thank you. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Thu, Aug 22, 2019 at 7:58 PM Karsten Merker wrote: > On Fri, Aug 23, 2019 at 01:49:57AM +0800, Luke Kenneth Casson Leighton wrote: > > > The last time that we spoke, Theo, some time around 2003 you informed me > > that you were doing so very deliberately "to show everyone how stupid I > > was". It was on the linux kernel lists. It was also very shockingly > > unkind. I can see some signs that you are tryint to be deliberately > > confrontational and I do not like it. > > > > As the Debian lists are covered by the Debian Conduct document, please read > > it and review the talk that was given in Taipei (it had a panel of 5 people > > including Steve McIntyre, if someone remembers it please do kindly post a > > link). [i found it: https://wiki.debian.org/AntiHarassment ] > Luke, please reconsider what you wrote above. ted has a history of being abusive, and hiding it extremely well. the term is called "intellectual bullying". it's where someone treats someone in a way that, to the majority of people, looks really, *really* reasonable, but on close inspection you find signs that they're not actually trying to work *with* people in the group, towards a solution, they're using the conversation as a way to make themselves superior to another human being. this is a form of "harrassment" - an intellectual kind. > The only person in > this thread whom I perceive as being confrontational is you, > while Ted has in my view been perfectly civil and completely > non-confrontational in what he wrote here. ah, karsten: yes, i recall your violent hatred from very recent conversations on other lists. i did make an effort to present you with an opportunity to use the resources from the conflict resolution network, www.crnhq.org, but i did not receive a response. your response may seem reasonable to you, however you just demonstrated - as you did on the other list - that you are willing to "blame" another person and are willing to *support* others who have engaged in intellectual bullying in the past (Ted Tso), and are actively supportive of his efforts to try that here. just as you were actively supportive of the ongoing recent and persistent intellectual bullying on the other list. i'm therefore contacting the anti-harrassment team, above, to report both you (Karsten), and also Ted Tso. i appreciate that it's normally just for events, however they are the people most likely to be in a position to speak with you, privately, and also to advise on the best course of action. if you had responded on the other list, in a way that demonstrated a willingness to resolve matters and work together, for the benefit of everyone on that list, i would not be reporting you here. if you had responded on *this* list with words to the effect, "did you know, luke, that your words could be viewed as being confrontational? to me, it genuinely looks like Ted is being perfectly civil. could you clarify, as it looks like i have made a mistake in interpreting what you have written? what did i miss?" i would not be reporting you here. can you see the difference between that paragraph, above, and what you wrote? do you notice that the rewritten words do not assume "bad faith"? l.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
On Friday, August 23, 2019, Karsten Merker wrote: > > and decide for themselves who is displaying "violent hatred" on > mailing lists and come to their own judgement about your > allegations: You've now violated the Debian Conduct twice in under an hour. https://www.debian.org/code_of_conduct Karsten: I very deliberately made a conscious choice to respect the debian devel list members by not poisoning the list with an extremely toxic discussion. I note that chose to do so *instead* of saying "ah yes I see your perspective, I see how the rewritten version was much less confrontational, I will try to improve my communication in the future" In other words, your intention, just like Ted's word (where he chose to ignore information - deliberately or unintentionally - that I had provided, and used confrontational language *and you supported him in doing that*, Karsten), is not to work together to resolve matters, it is to inflame them and to poison this conversation. Do you understand that that is what you have done? Please can someone urgently step in and have a private word with Karsten and Ted, I feel that because of their unreasonable approach that they are making me feel extremely unwelcome to contribute further to this discussion. Debian's Code and the matching Diversity Statement are extremely simple: the best tgat I have ever seen. The combined documents request that people assume good faith, that they work together to further the goals of the Debian Project, and that people go out of their way to be inclusive of all who wish to see Debian progress. I trust that these violations are clear and will be taken seriously. With many apologies to everyone else on debian-devel that the conversation has been poisoned by hostile intentions. L. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Re: lintian-brush adds redundant data
Hi Andreas, On Wed, Aug 21, 2019 at 08:47:51AM +0200, Andreas Tille wrote: > On Tue, Aug 20, 2019 at 04:46:23PM +, Jelmer Vernooij wrote: > > > > On Tue, Aug 20, 2019 at 04:17:50PM +0200, Andreas Tille wrote: > > > I observed that lintian-brush is adding a file debian/upstream/metadata > > > if it finds the fields Upstream-Name and Upstream-Contact in > > > debian/copyright. > > > > > What is the sense to duplicate data that we can find in a well > > > established machine readable file in another file? > > That's a good question. > > > > I've considered (but not implemented yet) having lintian-brush not create a > > debian/upstream/metadata if the only upstream metadata fields it can set are > > the name and contact. > > It would be really great to implement this. Considering the current > situation I would even remove the fields Name and Contact from > debian/upstream/metadata if the according fields are in debian/copyright > (or move them if they are missing in d/copyright). If some empty > d/u/metadata remains this should be removed as well. > > IMHO a good rule of thumb is: Do not copy any data from some well > established machine readable file to some other place. Agreed, having data duplicated in two Debian-specific files seems unnecessary and bad. > > At the moment, both the debian/copyright [1] and debian/upstream/metadata > > [2] > > standards both define two fields with (as far as I can tell) the same > > purpose. > > Neither of the standards provide any guidance as to whether the fields > > should be set in both files or whether e.g. one is preferred over the other. > > It would be great if some guidance could be added to DEP-12 about how to > > deal > > with these fields. > > DEP-12 is declared as "Work in progress" (without any progress since 5 > years) while DEP-5 is well established and decided. Charles and I > invented d/u/metadata to store publication information and it turned out > that there is other sensible information about upstream that can be > stored there as well. I'd vote against any duplication of information > in any way. So as long as Name and Contact are defined in DEP-5 it > should not be in DEP-12. > So far I removed redundant fields from the Wiki page[3] (it had also > Homepage, Watch and others I might have forgot) since it simply adds > useless maintenance burden to maintain the same information at different > places. Thanks for updating the specification. I think longer term it would actually make sense to put this information in debian/upstream/metadata rather than debian/copyright, so all upstream metadata is in one place - but that would obviously require a change to DEP-5 first. > The idea that lintian is warning about those fields missing in > d/u/metadata is not sensible, neither that some tool adds the values. > It was some Wiki edit away[4] to ensure you about this that this stuff > is really in flux and its better to not waste time on this without > discussing it first. > > I'd be really happy if lintian-brush would remove those values (please > let me know if you want me to file a bug report about this). I've implemented this. lintian-brush will attempt to update these fields in debian/copyright only and remove them from debian/upstream/metadata. Please let me know if you have any other suggestions. Cheers, Jelmer
Re: lintian-brush adds redundant data
On Thu, 22 Aug 2019 21:46:34 +, Jelmer Vernooij wrote: Hi Andreas and Jelmer, I agree with everything you've said (and changed in the d/u/m spec and in lintian-brush), thank you. Just one remark, partly a note to self: > > The idea that lintian is warning about those fields missing in > > d/u/metadata is not sensible, neither that some tool adds the values. > > It was some Wiki edit away[4] to ensure you about this that this stuff > > is really in flux and its better to not waste time on this without > > discussing it first. > > > > I'd be really happy if lintian-brush would remove those values (please > > let me know if you want me to file a bug report about this). > > I've implemented this. lintian-brush will attempt to update these > fields in debian/copyright only and remove them from debian/upstream/metadata. That means that dh-make-perl and dpt-debian-upstream should also at least stop adding the Name and Contact fields. I think this makes sense, we've only added them because they were in the spec and we already had the data, but they didn't make alot of sense to me (as duplicates from d/copyright, as you both noted). -- In fact we are only caring about Repository* and Bug* fields (the former were the reason why we started to use d/u/m in the first place). I'll make these changes in the perl tools; I'm just wondering, and that's why I'm writing a public email :), if other tools and/or other teams use these fields as well and should be notified. Or, in other words, I fear that having this change only in some thread on -devel might not be enough. Cheers, gregor, cc'ing the perl list as a start -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Rolling Stones: Everlasting signature.asc Description: Digital Signature
Re: Why keep upstream sources in Git at salsa.d.o?
¡Hola Daniel! El 2019-08-14 a las 15:16 +0200, Daniel Leidert escribió: Am Mittwoch, den 14.08.2019, 09:48 -0300 schrieb Maximiliano Curia: El 2019-08-13 a las 01:17 +0200, Daniel Leidert escribió: `gbp pq` doesn't work with this layout. Actually, it does, you just have to add the option --pq-from=TAG. How so? There is no upstream branch. So independent of the setting in --pq-from the command fails here. Are you referring to a layout, where an upstream branch exists, but is not merged with the debian branch? I tend to work with a debian remote and an upstream remote. And reuse upstream's release tag, that only works if the tag contents match the tarball contents, of course, where they don't, I keep a local only set of upstream/$version tags. Happy hacking, -- "Politicians and diapers have one thing in common. They should both be changed regularly, and for the same reason." -- José Maria de Eça de Queiroz Saludos /\/\ /\ >< `/ signature.asc Description: PGP signature
Work-needing packages report for Aug 23, 2019
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1382 (new: 1) Total number of packages offered up for adoption: 162 (new: 1) Total number of packages requested help for: 53 (new: 1) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: mytop (#935389), orphaned today Installations reported by Popcon: 1206 Bug Report URL: https://bugs.debian.org/935389 1381 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: policyd-weight (#935388), offered today Installations reported by Popcon: 231 Bug Report URL: https://bugs.debian.org/935388 161 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] sysvinit (#935416), requested today Description: System-V-like init utilities Reverse Depends: batmand console-setup-freebsd console-setup-linux coquelicot courier-authdaemon courier-base courier-imap courier-ldap courier-mlm courier-mta (18 more omitted) Installations reported by Popcon: 196277 Bug Report URL: https://bugs.debian.org/935416 autopkgtest (#846328), requested 995 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker Installations reported by Popcon: 1173 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 2888 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 764 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 591 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1764 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 863 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1152 Bug Report URL: https://bugs.debian.org/860116 cyrus-sasl2 (#799864), requested 1429 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-legacy-tools 389-ds-base-libs adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (115 more omitted) Installations reported by Popcon: 195380 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1133 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core Installations reported by Popcon: 45697 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 1818 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 7561 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1423 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero autodeb-worker brz-debian bzr-builddeb customdeb debci debian-builder (32 more omitted) Installations reported by Popcon: 12140 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 341 days ago Description: Linux container runtime Reverse Depends: golang-docker-dev golang-github-fsouza-go-dockerclient-dev golang-github-google-cadvisor-dev golang-github-samalba-dockerclient-dev kubernetes-node subuser whalebuilder Installations reported by Popcon: 2069 Bug Report URL: https://bugs.debian.org/908868 ed (#886643), requested 591 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn Installations reported by Popcon: 16447 Bug Report URL: https://bugs.debian.org/886643 ejabberd (#767874), requested 1753 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4 more omitted) Installations
Bug#935483: ITP: johnny -- GUI front-end for John the Ripper
Package: wnpp Severity: wishlist Owner: Michael Cordingley * Package name: johnny Version : 2.2 Upstream Author : Shinnok * URL : https://openwall.info/wiki/john/johnny * License : BSD-2-clause Programming Lang: C++ Description : GUI front-end for John the Ripper Overview Johnny the open source cross-platform GUI frontend for John the Ripper, the popular password cracker, written in C++ using the Qt framework. Johnny's aim is to automate and simplify the password cracking routine on the Desktop as well as add extra functionality like session management and easy hash/password management, on top of the immense capabilities and features offered by John the Ripper. The application uses John The Ripper for the actual work, thus it needs to be installed on your system. Official core (proper) version and the community-enhanced version (jumbo) are both supported. The latter exposes more functionality like extra cracking modes and hash types support. To download official binary redistributables and find more about Johnny visit: http://openwall.info/wiki/john/johnny Rationale This package is useful for penetration testers and is used downstream by Kali. I will need a sponsor and a mentor for taking proper care of it. Furthermore, the package appears to fit in with the explicit goals of the pkg-security team. The plan is that this would be a low-impact and low-maintenance package with which to wet my feet on helping out the Debian project.
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
"Theodore Y. Ts'o" writes: > On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote: >> so i hope that list gives a bit more context as to how serious the >> consequences of dropping 32 bit support really is. > > I very much doubt we are any where near "dropping 32-bit support". > There's a lot of "all or nothing thinking" in your argumentation > style. The topic of this very thread is how to avoid dropping support for 32bit architectures. So people clearly want to continue supporting it. > As Sam has said multiple times, what's much more likely is that the > set of packages that can't be built on native packages on 32-bit > platforms will grow over time. The question is when will that > actually *matter*? There are many of these packages which no one > would want to run on a 32-bit platform, especially if we're focusing > on the embedded use case. It might matter pretty soon: for generic-purpose systems one almost always want to be able to use a web browser; even various embedded systems do. However web browsers are one of the most heavy packages to build. > At least initially, the simplest way of dealing with the problem is > that maintainers will simply not build their package on 32-bit > platforms. I don't think we want this to happen if we want to continue supporting 32bit systems. But using a 64bit toolchain in an otherwise 32bit userland as the thread suggests we now really should start looking at will avoid this. It will probably take a few more years until we have to worry about being able to run browsers in 32bit... But I would hope that most people understand that using 32bit for new generic-purpose systems is not future-proof (and hasn't been for a while); even phones have started to move to 64bit systems a while ago. Ansgar
Re: lintian-brush adds redundant data
On Thu, Aug 22, 2019 at 09:46:34PM +, Jelmer Vernooij wrote: > > I think longer term it would actually make sense to put this information in > debian/upstream/metadata rather than debian/copyright, so all upstream > metadata > is in one place - but that would obviously require a change to DEP-5 first. Fully agreed. Once we have properly decided where to store what that's perfectly fine. In your great lintian-brush tool you have proven how easy the move can be - its just not the right time to do so. > > I'd be really happy if lintian-brush would remove those values (please > > let me know if you want me to file a bug report about this). > > I've implemented this. lintian-brush will attempt to update these > fields in debian/copyright only and remove them from debian/upstream/metadata. Thanks a lot. > Please let me know if you have any other suggestions. I'll happily do so. Thanks again, Andreas. -- http://fam-tille.de
Re: lintian-brush adds redundant data
Hi Gregor, On Fri, Aug 23, 2019 at 12:47:56AM +0200, gregor herrmann wrote: > > I've implemented this. lintian-brush will attempt to update these > > fields in debian/copyright only and remove them from > > debian/upstream/metadata. > > That means that dh-make-perl and dpt-debian-upstream should also at > least stop adding the Name and Contact fields. I think this makes > sense, we've only added them because they were in the spec and we > already had the data, but they didn't make alot of sense to me (as > duplicates from d/copyright, as you both noted). -- In fact we are > only caring about Repository* and Bug* fields (the former were the > reason why we started to use d/u/m in the first place). Since you speak about notes to yourself: We should also think about what fields from d/u/m should be stored in UDD. Currently the bibliographic references are stored but since I had no actual use for other fields these are ignored for the moment. > I'll make these changes in the perl tools; I'm just wondering, and > that's why I'm writing a public email :), if other tools and/or other > teams use these fields as well and should be notified. Or, in other > words, I fear that having this change only in some thread on -devel > might not be enough. ACK. Thanks for that very valid point. Kind regards Andreas. -- http://fam-tille.de
