Bug#528273: ITP: twittare -- A Twitter client for Linux written in Qt
Package: wnpp Severity: wishlist Owner: Dominik George * Package name: twittare Version : 0.7.42 Upstream Author : TabaréCaorsi * URL : http://www.twittare.com/ * License : GPL-3+ Programming Lang: C++ Description : A Twitter client for Linux written in Qt Twittare is a twitter client for Linux written in Qt with notification support. It contains support for receiving status updates from friends, sending new stausses as well as replying and retwitting. The user is notified through a balloon tip when a new tweet is received so there is instant knowledge of status changes. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: systemd is here to stay, get over it now
Hi Thorsten, while I tend to basically acknowledge your points here, there is still one thing you obviously did not get until now, if I followed along correctly. >For example, systemd has support for its own (S)NTP client, but also >supports xntpd (rudely leaving OpenNTPD out already). The commit >message >explains that the xntpd support will eventually go away. systemd, in its nature as an init system, starts what you tell it to start. There is nothing that can prevent it from starting openntpd if you want that. If you through a service file at it, or even an LSB init script, then systemd has no choice but to start it. That said, dropping support for service foo in systemd means that service foo dropped both their service file and their init script, _not_ systemd doing anything. If you have sources proving that systemd is planning to do antivirus-like signature checking on binaries to detect openntpd or something, then please provide such. I tend to not believe that! Cheers, Nik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/dea96464-5991-42f2-8433-fad892d19...@email.android.com
Re: Debian.
Hi, I have sent a reply off-list because I do not think the question is really related to Debian development by itself. As Teckids is dedicated to teaching Free Software (development) to children and adolescents, I saw fit here. Just for your information that someone has taken care of the inquiry :). -nik signature.asc Description: This is a digitally signed message part.
Re: systemd-sysv/shim in testing
>To make it short: I suggest that systemd should only migrate together >with systemd-shim. ACK! -nik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8667e39c-b7ef-4b9a-a686-f3c41f0ea...@email.android.com
libfreerdp changed soname without transition - rebuilds necessary
Hi, the libfreerdp1 package changed its soname without a transition and without introducing a new package. That broke binary compatibility of at least remmina and libguac-client-rdp0 [0]. I expect more rebuilds / binNMUs to be necessary. As I do not find anything about that triggered by the maintainer, I thought notifying debian-devel would be the best way. -nik [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758478 -- Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: bash exorcism experiment ('bug' 762923 & 763012)
>> Array variables practically imply arithmetic evaluation, amd this is >a >> shell feature which is rather difficult to use correctly because >> compatibility with other shell encourages both recursive evaluation >> and access to the full shell language in a few corners. I think the idea here was not "use correctly" as in "yielding the result you expect" but as in "guard against wreaking havoc": foo='x[$(rm -rf /)]' echo $(( foo )) Guess when the array index is evaluated? Now mind that it could be user-provided. -nik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8ce27f9c-7ab6-4a9f-9729-4fc417edb...@naturalnet.de
Re: apt-get install sysvinit-core removes gnome?
Hi, >but it seems there is some dependency in jessie which makes gnome >unavailable >without systemd. It is there because upstream requires it. There is no GNOME without systemd. This is not specific to Debian. -nik -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/09e6843b-eb29-4082-8868-d9617b053...@naturalnet.de
Re: Technical committee acting in gross violation of the Debian constitution
Hi, > Le lundi 17 novembre 2014 à 11:15 -0800, Don Armstrong a écrit : >> §6.3.6 does not prevent the CTTE from being presented an issue early. It >> stops the CTTE from deciding an issue before a consensus approach has >> been attempted. In this particular case, I felt that a consensus >> approach had been attempted when this issue came up for a vote. This >> particular bug has been open since May, and was discussed at length. > > There have been discussions, specifically on the debian-ctte mailing > lists, about upgrading to systemd only if the system is not at risk of > breaking sysadmin changes (inittab, custom init scripts). I do not see why this issue even had to be discussed. It looks obvious to me that a package should avoid changing or breakign anything outside it if it is not necessary. The CTTE's decision therefore is the only reasonable one, and I wonder why realising this needed the CTTE. That said, good job, technical committee, for saving users from touching a running system :)! Cheers, Nik signature.asc Description: OpenPGP digital signature
Bug#712219: ITP: libjs-forge -- a native implementation of TLS in JavaScript
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ** Prerequisite for geierlein, ITP #695204 ** * Package name: libjs-forge Version : Upstream Author : Digital Bazaar, Inc. * URL : https://github.com/digitalbazaar/forge * License : GPL or BSD Programming Lang: JavaScript Description : a native implementation of TLS in JavaScript The Forge software is a fully native implementation of the TLS protocol in JavaScript as well as a set of tools for developing Web Apps that utilize many network resources. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQJOBAEBCAA4BQJRusTSMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZPlA/+OfRqhDCFA7a0kWUldgDy iobdrYUqMGnmCTtmcQXJLR9NaZlDbqdgFGOILbpvGnw4c+xFGq+dUc9hSgSABudG gETIDUcbpjB97eDFIrzuX9TsIxgSVDqhB0FlWqy749f3ur3nsWLWPVbMK0vechze HTuKRGEoL42Vp7wN1Zv5yH23nOIrXD2vm6No1845//FEI9PEvw+3bIa6E3iy6zGn a4qVDSwoavJP+Gv7KzjYUOA5D9NOZMdJXCFw7vBA+x2841xbcnaNKuw8zsrSQO6+ vpYhE0fp/AuJiuynimcaPcHsWPdfxlCDovkLls7BQ2NoB40+thZlooJ7f1WZBGQy kAWfd3Bd4sfDHRtaTbNtAMuTkNktu7qfsKRSnSzCOw1NazGMVB9LNjVo4QYqtbwH aUZ7kwadCQfv4lAa/pDmsUK89YMTDJ5xuxBSja0XNzzwrwzRm3XLNdAGp6pIK0xS TNvcqcb3T/7ncwGYzFB9SpWAcgEWUC9jGO55dK44gjGmX5xWCAQO9o9wo4wvvfza s3Uwj4wkUyy8DRq/uT7hF6g4F2bnNzl71p5XmPeFM6qPzD0K+HXt7zT1TJuZ0VNZ OYDLJJ+rOJm9UqcsPbKMzFtlUqfHPuaOU2EkhXkgLnRZXJJiQO7AFkNcq7hb+cw3 fuSdHCkwUnkunouSZJh0Rp4= =z7ey -END PGP SIGNATURE- -- 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/20130614072302.18464.58286.report...@keks.lan.naturalnet.de
Bug#712215: ITP: libjs-gzip -- a pure JavaScript implementation of the GZIP file format
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ** Prerequisite for geierlein, ITP #695204 ** * Package name: libjs-gzip Version : 0.3.1 Upstream Author : T. Jameson Little * URL : htts://github.com/beatgammit/gzip-js * License : MIT Programming Lang: JavaScript Description : a pure JavaScript implementation of the GZIP file format gzip-js is a pure JavaScript implementation of the GZIP file format. It uses the DEFLATE algorithm for compressing data. Please note that since this is a pure JavaScript implementation, it should NOT be used on the server for production code. It also does not comply 100% with the standard, yet. The main goal of this project is to bring GZIP compression to the browser. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQJOBAEBCAA4BQJRusa/MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYuYw//R+i/turNPYPl2ULmawsl GZuU3EGMZ5UQk6zdsUqnpaBqXSO/ZtcoqcaZzysrjEu5oAwa0cml+bW8IeKroLHg 7bCdl1AhYlz3Sr14ce+VFmt0OG5Y06b/DAjEKH0G3MFwfPWupdk5VeeiAyEpQ3+L wTvsCVZVQ2TRwQ7OYlLLAV5C1zqpU+ShxLZA+qDuzWaQVoHgDcxjTG+0+Yi8gdKP Y1KVf9NbEisrKIEVG7wQ7amamWyxxdk8efJwE/oRW1EiUuuDf6LQcJt74sLXAnVu o5KlrwbqT35x57N/qXrgSuiwOy9RcrzcDUA3RZJ980qZRsa7svmVuVW4b0wdyylx 529O5YaXDdizUF+t5CO0Qz5O3oUjCq1yVaKuez7TUg6MiyUDEE0yU83wgDlJlUQi Ycjcia0qQ9UNHw7BaIBn6dYBpzNGGBCv32lbu2NMIXnXRskfv7L8JUQzLbC/aynT NDPNbcrGEoxD0Lvk6Kq6Bpi28sK+mtHAse7oMdbXYm0r6vgMlyuJ8WK+0myJAvpw BlsvjCpIwQVougu8ISUikK6oUsIcRTAmPvjT104iUqataoJtt8ZEx0hMhRp1pX2i fsJKMZMxyEGS6O5U/EGwcElGfJKViH/xugkYgtrpfmkXPqiqye+NP2kMjuS0348y gEtMVla66EbYUmEiafHJiLo= =Xjky -END PGP SIGNATURE- -- 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/20130614073111.19180.89391.report...@keks.lan.naturalnet.de
Bug#712220: ITP: libjs-jsxml -- XML/XSLT to DOM parser in JavaScript
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ** Prerequisite for geierlein, ITP #695204 ** * Package name: libjs-jsxml Version : Upstream Author : Anton Zorko * URL : http://jsxml.net * License : BSD Programming Lang: JavaScript Description : XML/XSLT to DOM parser in JavaScript -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQJOBAEBCAA4BQJRusunMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYAyRAAtaMhz0ghbyEUKWgdNkDn RRr2Zp6ZyzDhHVdb2gRIAPwK/VULIQ9P0C9AbJuwDr6tuPTMFmecIvfMQQjLbedj vxNf4xHMHYleZkgwo/QfV/kOnRBrg9Lc/nEud9cnU+fttYC56bz9voEbqlRCNMQ2 H+sOlhx5z4KAEIpmeGGOVKtPNvyWM3V/lugON9qw+4u0uAK7C4smUg7G4LuKEjHw m3z29g2cktPgxLOLn6gWjeHIqDw/OOgCgik1wF2ITs39mIwFhffmkfl371yKss9q 2vju2nc5B2SejBPJYyFCnnW3tcg4WzZm8DmATa7w5DgSco89U/7f5gVuw9MKEdup vW1kRletWtmM3AA5+yfXriFhIknQDOZFW7C6QAWnUtpPp4iyJvKrWmZYJGRDWvg/ /TxGGnRbUtYa+1uVFEeKi8W5Vgh3b+Rh/VKHGjzKUFyYJY1YPyWCkNkHB9wTZ8Vo 8spAXlswNafqRVS6GV6xC3+wJ5a74GWQx+fJas9sQh6onEwODtiLyUZ7mjuaUWa9 Q4BZeriw85PZy3ND5K0xrY3pd2geP1wQcgBh4ThxV25tQqhsRqyQjq6/82BClHgK y4TXCJLrwsJGQKSEOM8Mygb1JDypO7C8xuV7NvQ7+t6Z01paVDmIasKATNSm0vJk U8/fclVWrVgBWurdLa3WLhE= =5Jbo -END PGP SIGNATURE- -- 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/20130614075207.20383.20727.report...@keks.lan.naturalnet.de
Bug#720984: ITP: minetest-mod-mesecons -- Minetest mod - Counterpart of Redstone
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-mesecons Version : 0~20130821+git96011bc Upstream Author : Jeija * URL : http://www.mesecons.net * License : LGPL-3, CC-BY-SA-2.0+ Programming Lang: Lua Description : Minetest mod - Counterpart of Redstone "Mesecons" is a (free) mod for the game minetest-c55 (minetest.net). It's the counterpart of redstone in Minecraft. It adds wire and multiple receptors and effectors, such as switches, solar panels, water turbines, ... You can also create logic gates or even computers inside the game with this mod, thanks to microcontrollers and mesecon torches (=redstone torches). We use the upgrade clause (4b) of CC-BY-SA 2.0 to upgrade to DFSG-compliant CC-BY-SA 3.0. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSG55WMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pb1hQ//XHnfqjIzHCQDiYIV8u6o zwS/LnAlNViFEXaBF1piO84nuCyZRXkXVMLJxMtdDOB3E1mhU8PuiY/q+c5f4QfB M8uCCpCuVFLGlUAoWVPoXpD/eXwhWVw7tJTHqntrjy10yr3xtYuNETWZMp3t6v9I uYFajdZ51MqwRu/G91HOCLn3IEYR+20IJm0JDdmsZSzhKZkMoF2BrpZ9EDBxw9mh fPlKqr3dBp+nEJY5uVJvpM/Q1c0tTg6w0DeiM3SqUnjbBHRV3XvWtLx1yiRNQ9D4 UNtX+uRubq4Po2Teo0bC435wHcft6njvwZfWmplXGxnCmjjlQIwVqbzaPD/a3BXZ Lo/vN43fbzLv3mkL3b9GEqBHkPj6cUGYOq9hIxub66ou7QRV60J6A0YqPzMiLSnK V9GlF+igl08UeTOYMtRG5RCdEX5O+zQ/y3U/58KQ0fatL4yaCXfwPiJv4tBt0vsl eKSHJ9vxKdZHLBo7AqsxQ5CeXsyvTCbJiJopBAtf5j4xaIG9ZzFy6gNfphbRguYs s4fK7DFS55AQtMhBcgMRC+ImczBIstLzAA6hpYIEtzGqmAhBTLse2H2i5g1rvwjd dPS3/wUemwe4ycSMAyO6dLE5utZDBtB+IInuQQ/yO2lsHx/AxdCab0qNjM6gnJf+ IyjnXpiR1xLrofuIbRCW/r0= =4BlC -END PGP SIGNATURE- -- 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/20130826182845.31803.63957.report...@keks.lan.naturalnet.de
Bug#720997: ITP: minetest-mod-worldedit -- Minetest mod - ingame world editor
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-worldedit Version : 1.0 Upstream Author : Dominik George * License : AGPL-3 Programming Lang: Lua Description : Minetest mod - ingame world editor WorldEdit is the ultimate ingame world editor for Minetest. It includes functionality for building, fixing and more. It is primarily controlled through chat commands. WorldEdit exposes all significant functionality in a simple Lua interface. The API is useful for tasks such as high-performance node manipulation, alternative interfaces, and map creation. I am contacting the upstream author because of the AGPL-3 license, which might be an issue for Debian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSG8ZdMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZoRQ//UbI+CTmWIz+qtaLN9NW0 wbwfN9S51SJm4sVclY+L4zoZzVhVPDocxqfPaFFt12lQbaDkRMiRkUIaocfrHdZN ebY2U/wFhrsEKuyUM4hd7RJ67lzDWcR/j/3Rb7v+aoivqO3Dd40h62LqbihIZUJq 1YjhVaeaCMECdVoOtNibhRmIgLTOYKcrc2jnNhMIbjgn3lyRHHJXTVfEAib7lo9W jAWhas/Fql2KJLOKCAGqpgRbIQe413utty5X7JaxKiZs5PPxgpea9Wn6VDcPElyU PbqxuGT+XJ6PEbGgzozE8WP2RoACQhLwOedPMGyZUjcjoZqxtA1NEaq8aE5ArFEE qW0gUo5/rOw6WmtjCPYnZcboUKZP1HCm95w6P68QcI+KDxoDCuhh4nTb/tKUcAfR 6QZjKVyjC4IZYcANAR9aGttmYE/9A44pFx6ytRvKlUXr3CMDTEtv5WX01ZAL0HXW +FLjdgPXRCvEOyepqeeynMM6kB+H/G2xNz+5RHl/pncpdxsM0m+VSyxciasJIK5d V8dYgWkTVd4qxF/JyztlcWdegk0Ikm024hcC7GnL2QWHa/exE4VUnHcKfvEvf2Xg H0D9OAMXKxGtjcN1XJQGSeIOwt3YC3mc3tTvWBHmeAINiLhO/RxaSYeO65BBlxSx Qob6cWPb9CcARUIeOdvqs7A= =dnhH -END PGP SIGNATURE- -- 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/20130826211930.22924.5770.report...@keks.lan.naturalnet.de
Bug#721073: ITP: minetest-mod-pipeworks -- Minetest mod - Pipeworks
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-pipeworks Version : 0~20130827+git59362e3d20 Upstream Author : Vanessa Ezekowitz * License : WTFPL Programming Lang: Lua Description : Minetest mod - Pipeworks This mod uses nodeboxes to supply a complete set of 3D pipes and tubes, along devices that work with them. Unlike the previous version of this mod, these pipes are rounded, and when placed, they'll automatically join together as needed. Pipes can go vertically or horizontally, and there are enough nodes defined to allow for all possible connections. Valves and pumps can only be placed horizontally, and will automatically rotate and join with neighboring pipes as objects are added, as well as joining with each other under certain circumstances. Pipes come in two variants: one type bears one or more dark windows on each pipe, suggesting they're empty, while the other type bears green-tinted windows, as if full (the two colors should also be easy to select if you want to change them in a paint program). These windows only appear on straight lengths and on certain junctions. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSHN6OMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8paxwQ//ciWBNPdw1jVxWjktitCk krgqwyL/hb9mYgoWMRQQHhmM/TpuLhZMpQ3IkP+nn9jrxgkyrIP6UGCj2BcVXi25 DYxl9w6ehaWmEX35tHKXUR3hHPCLs5viAJrj4hhVC7LDWGKiD0JKcsZf5NrMHrQb rYfI0mHrLEsIgmITHj0iz0WaioXa5o1v+NVGfyMhSYnMgbRwWI9PiytNKbDQ23fw YW9XjxPX7nFnJk4S9EmDw7a+E56USYRaOeS6/mMPp8DjNoou/xxtEi+p2nTqIsWC yFCblAwDy2cuRc1GpWoCoIN6l6rQtpD+OEnf6MTbOl4DVLSYVaTkiop7fSrT1VqK un+v0pE2Ut5F2Jex6/HVtf4XkhDDi/SUW4hzAsQxqUQ45nObhEUvQT4sabxWqEH+ wW8RMyWasOMCiVM2ZqzWnJ+ytbo+SAgWmVGnbKfO0D4xmsIUrqWgKHOE1NV/TB/O J3v7NU/FE2tFSOfnAV0pNjp/1SROrgaIwR5ljkiAkJDf+SW5tPSdQ6bvoY1glpMR TqtdB27RUVbqQMSvGaoEuw2MGZsFQQIXN39R93CxFbvSLfAFZqLM3+Qsgz4ElT6H Zgvy2dgSeddJUzthm/ZiFqk35Dedjtw1YTKDJquiSSAQonMjjEBHZePXp3NKHT2e lE4xh01xgsfQNxSb0jhKjLY= =abSK -END PGP SIGNATURE- -- 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/20130827171454.3847.49739.report...@keks.lan.naturalnet.de
Bug#721086: ITP: minetest-mod-plantlife -- Minetest mod - Plantlife
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-plantlife Upstream Author : Vanessa Ezetowski * License : WTFPL, CC-BY-SA-2.0+ Programming Lang: Lua Description : Minetest mod - Plantlife Plantlife is a combined form of the Flowers, Jungle Grass, and Poison Ivy mods and has been significantly rewritten and re-organized. This mod supplies all three of these components and should be 100% compatible with mods that used the old versions. Its purpose is to add various kinds of flowers, cotton plants, water foliage, poison ivy, and jungle grass in a few sizes. All of these are spawned as normal nodes and can be collected and used in any recipes that depend on the old mods. Spawning of plants is sensitive to the amount of available light. Flowers, cotton, and waterlilies only spawn when there at least a signficant amount of light. Seaweed will grow only in dimly-lit areas. Jungle grass and poison ivy also grow in the daytime, but require less light than flowers. Growing of jungle grass and poison ivy will only occur for plants that are on the same surface that is necessary for them to spawn on, so they won't grow if placed on e.g. cobble or homedecor flower pot, etc. This doesn't affect wall-climbing poison ivy, since it uses a different growth pattern. All plants use perlin noise to keep where they grow under control - no more random spread of plants! In addition, the density of the plants in any region they appear in has been fixed and brought under control. Poison ivy is found sparsely among junglegrass, but will not grow near flowers. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSHRDbMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYelQ/9FmjHQeIMhBOHUvSXv4+B MemhvRQkuv/K5r5JwrU2TXGA19WLLGFz2o4PdLRLkyQieGk6lFmVpbh/6HVUTvqM uzZJFgpxBmiZYfGzOVlfEeF+24b0ghePUI7ggK4YkaiI8NaDyQ0Ij8b31iTXidcE 1nRjpIUnAVatatE+q9Uz+ZFzvq7dqYPsVw73pPp0rbggedpwcaLlKX5JXfvV0To3 FG/mPy2s+wvv2/a8GqvLk/7PGU3s/3RxLqsoBlVOspcvFHX2RiKQVTTDgLnOrt97 QNEgGS/HJg8oKb3ow8lfmdWWjy+WbEgE60KmxSe6BVH3FagUMklF1S/cf0U/NiFB LEUaKiyXfFDmbpXf1+cUCwhZiRjbSK8EIweEjUcRLd7lNdwXv5WLNcash8xUcAKo AFzLUyylrkktNwX4gStb5yXneE8WjAcrQVGlwd3+97mPgZaakdyOlUV2jF5Y3awh 3CgEKl/pDGUwfCMpnDbaX4ZjAPpp9Rph0UxebNPQ25iYnX6SFd+kSFyE1ZWrT1M8 tsq74gaj2/LoHYUUEyr4CTf/By1+jQZT8H2byzI111UG2OMk8H4sZAz/lYPdZBRE /FqjpFAEhc/amyQ7YywXYjazcptCvmLNxKePQLpMJ98FelEIU+jwJhVOUPNVfZX5 YHTHHNF4bXJVsXL4umdAxHs= =Y7fg -END PGP SIGNATURE- -- 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/20130827204931.9689.13916.report...@keks.lan.naturalnet.de
Bug#721121: ITP: minetest-mod-moreores -- Minetest mod - More Ores
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-moreores Upstream Author : Calinou * License : GPL-3+, CC-BY-SA-3.0 Programming Lang: Lua Description : Minetest mod - More Ores This mod adds copper, tin, silver and gold in Minetest. This mod also adds three new sets of tools/swords. . All these five ores give lumps upon mining - those lumps are smeltable into ingots, then you can do tools, blocks, and locked chests out of them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSHbunMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8patDg/8C9CsZJfpqYzV+9jw9WsT /4bMO54sUC0zZPG/CsPdn8AfsbNp9xjSR9+2x3G2/7/ikr/ELJl9VldUNqSs6WGo jVBjibiSlKrE7BpwQikfjQYV9kpLKSyxrJNeDn5BT7n3FHLUCJdbNbdiMHyjbEMg zsyA+wrG6dognbLggGOj7cpIU81EBXYTzsv6TsT743/VmTNsnZR548B85IUIMsPi IzxBWKizTu5Xljtp7LxjABPbyLd8DErnEEjIhsgwzl8VqKFfkT/n3Oh8QcS5rsM2 TALfnKa0L5bg6oZXkUXEsyEQcMKmrBtpoLQ9oRVHy+5P+mvO6MhuT2cx8Ga5WhJ1 DeBrlQwI89FpPbsJxipNhkbxe107qkQkiHSguX49PEE0Ro35czUaHtMRzepEg825 UcroHxpOcMapTBPBDWbncPsKNlloiqQFW2EDj3BjdA8xRxkqnQx20yQ+BkgKr6xa VW2C/ako/S8vAWOaCMYO8rZ/wXFaE+B8q08nCqvs2wCNctGtLgAoHoS+cVOTIrJk jx+aeiC92EASnwlyNUKqv/Ut8msaWqkhN/5gcAict7+fJYOLFlR2AJRCYFpW+v/d r/cd2QHWiddqKIWlMbStSYXkfBqdNivWC6H1HiO2vaP47O27OErj0SUKBN4Bs7K6 JqLgVcbLVT9cBzinG93fvDE= =l9ps -END PGP SIGNATURE- -- 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/20130828085820.11963.91211.report...@keks.lan.naturalnet.de
Bug#721193: ITP: minetest-mod-moreblocks -- Minetest mod - More Blocks
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-moreblocks Upstream Author : Calinou * License : zlib/libpng Programming Lang: Lua Description : Minetest mod - More Blocks This mod adds some new blocks, most of them don't have a use other than decoration. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSHnyhMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pamOQ//Y3hSZ6SpsDc3bJgZcx1R zimzqffEXL5U35AV7Mc3hhDd09g/gN/aCR10vXQvxSbkoctNVO2DjYH6tSzmp2CZ 6UbTo2Wc1yrc7CCf2SqjX+patSUUnvkSE0Tf0DHOQluequj8bVv+xxXtuWPfzcaZ b6fXxIROMlPMAEibW26uGRUnXC0wPyroep0VCHvnMHS8999/HJzeqVQk+sQYoDM+ FdZdowCHDQRwPeHFp2U1NRD8tJ9OdUs53oG3mzWAnvCGWuC9oFZ8cKn4nW/TLBsL LptJ3YrnUZoR/K2/5kQ+SqDLM2Ls5a0OXE28ZCuc4wO9NopPrJQ91a116ShVO7BY 0fEGYJNrwuvz3SzF3V7IqWb5RX3wQAjtF4TASxTGT47G4iqmxHdOiwgu9W1viH8p dIVTQeyPN+4923ydGaJoNxxCuH7fJtXBT5n2EW16eRCEYkAFtQ8c3r+tlUjV28fP uPlL9rMPD8JlhN7vuu/BOujt/b/9/KCDiyP2a/8fx0DaEVPY4i/ayhjHPgDlDyF/ rcPgS1iAqEra0W0iKW3SFlkDyIwxyukF/wU6cg0Apj531XN9Z1xZXeNCk2YrxgLZ rAcSi1i38//KiNsY00wE0VVJVV5cIXC+ixQun9F80Jjntw7xgkif7tmhidLHsX05 Idt0hbocgq8oPh4F9EvnCrE= =iSCv -END PGP SIGNATURE- -- 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/20130828224137.16154.93130.report...@keks.lan.naturalnet.de
Bug#721197: ITP: minetest-mod-technic -- Minetest mod - Technic
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-technic Upstream Author : RealBadAngel * License : GPL-2 Programming Lang: Lua Description : Minetest mod - Technic All technic stuff for minetest. This modpack includes blocks and tools to build complex machinery within Minetest, an open-world sandbox building game. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSHoUHMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pbbNg//XZXGZ3Qzz/kCFblOLDrK fTFMxT8jO87Ixe/yfYP0h2nRVeYKayfNoEB/ZTHzL9gi99CxI78Xc0Ciyb7S+MS4 yo3C3UDvpihCPC920jep9+RxYuQazk0L75S7x6FgMSaKTVLtC+TXg6ij8Af66mQx Qg2NoiF7T7IN69FkfCj+rgAgI8IthWBsGalJjmJGviEFpvdLg5dpKA0UjQuYHBZN EXkxnF/3OgH4sjyWSpZCWKSFYgyk/J/8ewZ1iBPysGHqVDuDW58UINl+zcIMiRvv TUPLmsmbDQte735b8/oVObr8PFgtC3TGGDSg+CO8Bxip+0F2RJr0BoGkkUZQCrMD qunAusB2BKBbHlCyC8Yi+V7o17RU+OyMwasZtLj/bQyt7wcH5x1omQi7sPZPatgq VGVZPp34OAX6CQNsY9WFp5ifEtwq+/2QzN0ZAgR+mtpsHdcVcMlWBPTcpH4z7ypB HvNq06QOM2imkk8AvkRIz90rVBHH5YYw/dWdtLBZC8l5aYxiYc57EmK2TkTGagr6 UpB4EtjtzKuHVV5XF9k6gyX1kMPKuMTIQWeAPjipKak/FPauhDmVFGXpT0MqYV30 SLtA5yuj2MwYR8UQoF596haNyTbnJM9Yys00yZzFXkpzMN0FCCyuv0sqqlyvUNUl 9OU0UQWG38QqXeRd5JGJEkw= =MKJz -END PGP SIGNATURE- -- 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/20130828231728.29168.32605.report...@keks.lan.naturalnet.de
Bug#721200: ITP: minetest-mod-moretrees -- Minetest mod - more trees
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-moretrees Upstream Author : Vanessa Ezekowitz * License : WTFPL Programming Lang: Lua Description : Minetest mod - more trees This mod adds a whole bunch of new types of trees to the game. The trees include jungle trees, oaks, pines, firs, apple trees and many more. . The mod uses the plantlife library in order to allow the trees to grow from saplings and create biomes. It can also use the stairsplus mod from moreblocks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSHo67MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZCpA//Z35cVZtmC7snuYl1lxP8 3oBaqWpGQjAGUzeP+9bEk1SM/1vwP/wToWw0wX4v7y/BxUQ2sQhwEZdZSnqeH20C YoM0zeS2PQwBhgxLVq+axU6XyT+EgMV0Hclszsz6J7nvDT+PQOYjUM5UrAgS7ZGA aJ9Gs3+5QArHeETc8Y3WGB/pbKtuC35KduuAYbkR/sIDatbgcgzb9c1yaA/S/LCI eKCGcYA0dRoV3w5Z6FHMarV9smOgQIQ35nZwTWSEbgWXynQJaB+4HNIEG3lmJnjG m4OEe5j7DeTNzS1dwXL3DSx3l6c2gtX4S69g7BP41F2YqxsT54ARt5QHU24ycmsP B6gBM8B4BlIx4ihiJrOX7H2r1mP8pKafhDB8NQdS0L2okhvOXDONTlDuIl63e+ji e0e6nN8Sn7jVmEeTweFmNEbRbH6d38cFYAI7MFhrhd55LmE78AqMBvwsNcADB971 1WJ02u/vjttMHu4/2Tk22RcWzyV+pvQFek4dJVfO5DPqpnRVphB6bH36EQxAKNbY wDHYKLvwWGO2+gH6Ls1FDcEJIvcLMjc30vzzUebTWOeBuUkbM8MLqu95YMqtaGjy RLvk924pCYVQwAn/BD0XMDWolGNUDUz/wqf3tye08jyZo7inbOxdZOP2iKL3U2Ir +uRN5cM0tLWB39MpwJvOk8w= =jkno -END PGP SIGNATURE- -- 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/20130828235851.17864.77136.report...@keks.lan.naturalnet.de
Bug#722309: ITP: minetest-mod-itemdrop -- Minetest mod - Item Drop
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: minetest-mod-itemdrop Upstream Author : PilzAdam * License : WTFPL Programming Lang: Lua Description : Minetest mod - Item Drop This mod adds Minecraft like drop/pick up of items to Minetest. . You can drop any item from your inventory and other players can pick it up, adding it to their inventory. . Several other mods use item_drop, e.g. the technic mod. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQJOBAEBCAA4BQJSLr3aMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pbsHRAAv0j4gVWuIGYT3Lu9mj/l Kfp27LgJklWpdr0ABIjQhWrnEv9R4NBAiTAFbAMJh86+L70NRrqZmd6+R+tpvsEv XmXY9SxbJp5qIkc777rqf7AwNTi0L4tqCiexyeFSxURVFaOGgy1LNnAF+4aQ+muA lEWwDXfW5QGgAdzE4fqmSKnXijk/murq2c0zfus4Lyi2Cx1jA+aS78e+AVUOqjXa dv4i4ifzz58U7JZGeJojFQnvLXx2EGx/TKXAWEBAn6KiEIGQ+cLPbxlkzhZuV8Xr gwu/RWvZLrme6EIR3xeXgqWnmL+6RcUDrUGkNguIAhuOAUsZmQGnco2GCDEbgvSU fUrU2hGBuum7+/1aEi341dIbXg8/x7fbCLm9rNwy25hMHmu7Ckw6gFmv3aIg97VW XDrChllQdq6XGRdlvoBGckJx0AqdjKKobck9ZOJBm4DPyI2GpBRocKMLlVv4Ueju MNw3KhuUVHU3cgf6UE0wghBs2CUKpzrEMgfjT9FAdYHSNEfe6e1ioiuejeUyI3DQ /9gibjYkywVsyEeDLH0TEj7GEQztXRTILhYpA+dHNyZgQGfZjRKnOfJxh0GkExVz AQxc7WH0ysIs1JdqOlFhcmLOAhdYsH2ml3WXDcReaRCYwcpOlMI2t9tWhzGFOKBp Vbp73g2qfdkB/F6BqP855dc= =U2LO -END PGP SIGNATURE- -- 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/20130910063610.32555.89440.report...@keks.lan.naturalnet.de
Replacing unrar-free with unar wrapper
Hi, maintainers of unar and unrar-free, as you might have seen on the BTS, I have today filed a bug report on unrar-free and revisited an old bug, both of which make unrar-free largely unusable [1][2]. I found that unrar-free seems to be umaintained and has not had any commits by upstream for the last 6+ years, and important bugs are open and ignored. I found that the unar command from theunarchiver, which is even recommended by the FSF [3], can handle multipart, modern RAR archives just fine, only the command-line is incompatible to unrar-free and unrar-nonfree [4]. One issue is that some tools in Debian, among which are usenet clients, comic book readers, and others, rely on the syntax of unrar-nonfree, for some reason I do not know, maybe because it works, in contrast to unrar-free. I guess the command-line compatibility in unrar-free has been added for this very reason, but it failed to become a drop-in replacement for unrar-nonfree because it exits uncleanly on passing some unrar-free options, and in general does not provide the functionality of unrar-nonfree. My proposal is to remove unrar-free from Debian, for the reasons mentioned above, and add a patch to src:unar that include a wrapper script that provides a command-line wrapper compatible to both unrar-free and unrar-nonfree, so unar can become a drop-in replacement for both. I would like to create th ewrapper script and resulting patch, but first, I would like to hear your thoughts about my research and proposal. Cheers, Nik [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724295 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270751 [3]: https://www.fsf.org/blogs/licensing/free-rarv3-extraction [4]: http://manpages.debian.net/cgi-bin/man.cgi?query=unrar-free -- Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Replacing unrar-free with unar wrapper
Howdy, here is a short update on the progress of the compatibility script. I have put together a shell script that accepts all command-lines that unrar-free or unrar-nonfree would accept and correctly parses them into internal variables. Doing so, I found that: - Both unrar-free and unrar-nonfree have a ridiculously ambigious command-line syntax. There is no way of telling whether the last argument is a file to extract from the archive or a path to the output directory. For now, I decided to assume that the last argument is the output directory, but I am considering applying some heuristics that check archive contents and direcotries on disk to determine what would make the most sense. - The unrar manpage is incomplete - there are more options than are listed in there. The script does some extra work to satisfy programs that call it. I use nzbget to test the "API" in a real-life scenario, and it makes me scratch my head every few minutes. Mind you, the way nzbget uses unrar is not unrar's fault, although by now I'd really go with assassinating both nzbget's and unrar-nonfree's upstream if I had the choice. One thing is that unrar-nonfree _does_ provide a sensible exit status (0 on success, >0 on failure) and nzbget _does_ check that, but additionally it checks for a line containing "All OK" on unrar's stdout. Why the…‽ I made my wrapper script output "All OK" if calles with the unrar-nonfree syntax, if the exit code of unar is 0. It works good. I am trying to add some more compatibility by transforming unar's output ins something that resembles unrar's output because I herad of packages out there that parse unrar's output for other reasons than determining a successful run. unrar's output appears to be an artifact from the MS-DOS era when human-readable tables and BIG CAPITAL LETTERS were cool. Thus, unrar l, which should list the archive contents, lists a hell of a lot of information nobody needs. There is unrar lb (list bare), which only prints the file names in much the same way lsar does. Sadly, both commands fail to list all files in the archive. I use an archive that, as a matter of fact, contains 5 files, listed by lsar and even unpacked entirely by unrar x, but unrar l simply does not list more than one file. The RAR format's quality is arguable, but the software surrounding it is a mess. I am doing my best to provide good compatibility from my wrapper script - at least, it cannot get worse than unrar-free ;). I think I will send a first patch against unar's Vcs-Git in the course of today. Besides, I would really like to hear the unar maintainer's thoughts ☺. Cheers, Nik -- # apt-assassinate --help Usage: apt-assassinate [upstream|maintainer] PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Replacing unrar-free with unar wrapper
Hi,
> Not directly related to this, I noticed that unar depends on
> gnustep-base-runtime, which in turn spawns the gdomap daemon. Is this
> thing needed at all?
I also noticed that. It comes from ${shlibs:Depends} in the package, so
I figure it is indeed needed (the runtime, not the gdomap daemon).
I have added a patch to bug #717773 to have the daemon disabled by
default [1].
-nik
[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773
--
Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben
und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)!
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296
signature.asc
Description: Digital signature
Re: Replacing unrar-free with unar wrapper
Hi, > This all sounds like a great idea, but I would suggest that rather than > attempt to be command-line compatible with the existing tool, you > clearly define a set of command line arguments and their corresponding > semantics that you *do* support, ensuring that it is an accurate and > correct subset of the behaviour of the original tool, and implement > that. Ensure this covers the behaviour that is relied upon by the things > that you are aware of already (e.g. calibre). Otherwise 90% of your > effort will be on re-implementing esoteric or awkward features or > behaviours that are not practically required. yep, that occured to me today when I found that both unrar-free and unrar-nonfree are incompletely documented and have some antifeatures I do not even no any justification for. I think I will go with your proposal and hope the unrar-free and unar maintainers like it as well. Cheers, Nik -- Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: dpkg-buildpackage creating uninstallable packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Norbert Preining schrieb: >On So, 29 Sep 2013, Stephen Kitt wrote: >> > Uninstall the libc6-amd64:i386 package. >> > See http://lists.debian.org/debian-mentors/2013/03/msg00139.html. >> >> But watch out for http://bugs.debian.org/699206 - make sure you have >a root >> sash running somewhere so you can relink >/lib64/ld-linux-x86-64.so.2... > >Indeed, suddenly my system was hosed ... nothing did run again. Umpf. >I managed to get it back without knowing the above bug, but >it did cost me some nerves. > >Sorry, might I ask *why* bugs like this that break *all* other software >are tagged as important and open since *January* ??? > >Norbert > > >PREINING, Norbert >http://www.preining.info >JAIST, Japan TeX Live & Debian >Developer >DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 >B094 > Simply put: Because you made no effort to fix it :). - -nik - -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSST1JMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJQMXB/954UMli1fbKU4qTASJ+mOw 4D7txAdR0MUUgKHrelZeJ4MNPsstOvGybqtd14NdrG0WnCZM3w1hWv9kyYtX76n4 ot7N79zReheZJsSj/uQ0nVjPL6N9nut5ONzd+suLQhThg0dHCzuUiPUC7hPNmKEC h3r7pLw3zw/f8cNAn4QA4XvBfoU2TS5+Il6YZ0ODxGvJE6mdeGYO3SXh09HmkABA Ec1KNDNOs5zOHQjNnb75+9WGZXs/5DJnTDxrMAkPS8qbgSfT+N+RfTU9WBD2f/Wv u2JjbsNWqsDZLkegtKgOsrWuGIA52inSD+jIaXhGPH6Aviv4bcw+5qYdTj8F5jn2 =fgDw -END PGP SIGNATURE- -- 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/20155ad1-6366-460d-86da-0388793af...@email.android.com
Re: dpkg-buildpackage creating uninstallable packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Norbert Preining schrieb: >Hi Dominik, > >> Simply put: Because you made no effort to fix it :). > >Thanks for the very useful comment. > >Yes, I care for RC bugs in my own packages ... and that are quite >a lot. So no time to fix RC bugs of other maintainers. > >Norbert > > >PREINING, Norbert >http://www.preining.info >JAIST, Japan TeX Live & Debian >Developer >DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 >B094 > Hi Norbert, I do not filter my replies for DDs or Non-DDs. If you accuse everyone else in the community of not caring for something, I accuse you of not noticing it earlier. I am certain everyone here does a great job, so I feel disappointed by such accusations. - -nik - -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSSXHtMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJUXwCAC0WiHHGm1MU0pkxiCiXOAh SXxItktOPHms/FTnp+CTxp+ZNwEtfwH59e4UpkFYdUIkiK9uxIwoDXhJ6icY7rV3 H7/IG+Tx/3L8+pSIrMAQEvXcBrscXfKjrQexPHTlO8wgASP0BL3hUq2YHzEn9dRI up13o2LP/lCb4w0dSV4CG9QeBlJuwEteVdNnLw5csnKYhTNWRY+wvPmYJHEiGJit 0olbEUWwqX4JZd+TFmHNnbG2xGqzgOR3EXUQApxkgRpzEL+rdXowZjmmc/AEdXya imT7WL+ckycSLb4dwUMT9B23gQTwqaOdt771e/JEsRYHT1TD2cBh7IJInl5pL2sK =xuJw -END PGP SIGNATURE- -- 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/c8929909-a597-4928-82dd-4f29ae8ce...@email.android.com
Re: how do deal with versionless mercurial software ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jerome BENOIT schrieb: >Hello, > >I am packaging a versionless library software maintained via a >mercurial repository. >Is there any custom for this case ? >If not, can we use the version format 'hgMMDD' ? > > >Best regards, >Jerome I tend to use: 0~MMDD+hgXX It sorts just below anything upstream might invent later (I don't like epoch). - -nik - -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSTCRcMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJai+B/wIpL0jbgsUcu8ISj/yEFe9 EjhMAld0veQnETq6yZhXrWM32h1Y70N/4BDVrt4NySM+kqn3wFZcQ3EAuEpYACg8 d4HxdVhvEfz8XO9nxVHXCwXoDl1pYvKkOHPJTxjDOWrwvNnxWjJklzfep2TdlefO Tj64mQB81IBB+ayKgy+VkSBPUZFj2TzHznteTHllkPTV5HTj0+dw/lqaq3P9oz3R 1C8a8Oi8k6v8YmyEN46H9PM7MSfuS7q41CU4Ri8NAEPjqsTBlQfLpnc3YdLVBtz5 P4hKEVkCob5pQYXKEng7EGFe0QNxPD+NQlZV7W2UOuuIkU6iPsodxnGtt4YPd0vR =aq9p -END PGP SIGNATURE- -- 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/d4f88f68-a946-4b6b-bace-e5e52e00d...@email.android.com
Re: how do deal with versionless mercurial software ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, >What does 'XX' stand for ? The short commit hash, as proposed in your initial mail. >You should use a version derived from the date only. This way, you >won't be in >trouble if upstream switches to git. I absolutely do not see why this should be an issue. Using just a date is not uniquely idemtifiable. - -nik - -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSTCgeMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJeL5B/9SdDXgBzfNxRFvUrC9BEJN YQu8FwLcGRXhKYPVezCWkqV+yNocO7w7UZg3bgfFJgEOWhp3Yzt1xLKhtOMdcuqk 7TV6M3/hvWqujGeDPRoLmYKr0OSUMR9pVRlpzWcWS9g24Mw1fFj5iifCv36hOK3M ZwPjTpu38B02UcvNJ0LJsbYeLk1FEFz/9gouqYGEHx8llJwe6g33OVpIqEzK3dBP 0FuRMlPn7KTmnZSnODtdcEz6WIWZ0cwihWdgiRWnUuB+V+VLhWbuuycivIv0h62E RV6/JLf5NU3tCuKr6+VzxjZeaGNfjf9SvkA9wsDMMKoVpVyGWE3aDE4zCp37clSL =4zTf -END PGP SIGNATURE- -- 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/8e227d40-46a1-4b67-a34f-9b1d46ffb...@email.android.com
Re: how do deal with versionless mercurial software ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >0~MMDD > >should be fine. It isn't, it is not a unique identifier for the one "release" you are packaging. - -nik -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSTCxtMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJfo8B/9A3TT7GJcYern0/bNeVWZu YQwYkS/7G9M6890zSB01ACW8Ieh8LUz3Zqo6jAlyJciw5eiokF6ueAA32dgetusj tgv3jexN5zIWBn6fBmOIBjFtvVPDY5k8lW0UMdkjXbfLxuucUUGPnQB2QQRDw8lg s+TGfZEnzlkgP5K0+vu1uTd2GsI20MlRKhQn7nM9TEcCO8ElB3E8Ojp1czDgQAvh qdeRBc1Fk2BQ142FSxmGb0vVvjmSrNU/ByMrwK1xTn6Yl4elVKYQIdo9L0zQuWxm RpsYfo4EXG6nW0OSs2jvEeYEikx3XCHh9BOW7kLEYFaGIGQZALqhho2yieYCmZJq =afA2 -END PGP SIGNATURE- -- 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/ca481637-535b-4a10-8483-73c89c847...@email.android.com
Re: how do deal with versionless mercurial software ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Wookey schrieb: >+++ Dominik George [2013-10-02 16:23 +0200]: >> >> >0~MMDD >> > >> >should be fine. >> >> It isn't, it is not a unique identifier for the one "release" you are >packaging. > >No, but it can be a sufficient identifier so long as you don't make >more >than one release a day. > >Which exact tag/branch/hash/whatever was used for the orig tarball can >be >recorded elsewhere in the release. It doesn't have to go in the >version number - that's a decision for the packager. > >Wookey >From a power-user point of view, I want to see what version of a package is in >Debian by looking through the package lists, without having to download the >source package or some other awkward steps. A packager might package a 3 year old commit now, and use today's date as version. You see that it does not serve identifying upstream version in any way, it's just a useless piece of information. - -nik - -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSTDANMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJXyZB/9MYekwEsdPMe/RC7QuaDUa CxsSvL0wXVTn/MhA52cTv2VLJb8TTLnlNywc0yJPL0yMTrj2cZJzi2kcpWX7WXZX vawbjy4UY+pk4GqCUWdU1lcCFhjz9Lr5FNUIZ56UbYPbv9OFYpsNeoUCxUU4ITUp UF14dAf4kYAsC/H0ECvEuPcauFqRQSo11Nrjdx0QA3N19EETA4FMcmB05muhVUTM ux2ePdDmfEPPk2alnNyErQUDgfVhKPCO8S1FUz32iTqhnjQcIRyEElC1Y8HrTiUH C1c7UxASQR1H3+SdSEdVqZvXvb/Hpa2g3JyUM2xnyjHDNW8AF8DcolHu80pA3AIe =ocrV -END PGP SIGNATURE- -- 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/9ca73438-e12d-428b-b337-8c5f76330...@email.android.com
Re: how do deal with versionless mercurial software ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dominique Dumont schrieb: >On Wednesday 02 October 2013 16:05:18 Dominik George wrote: >> >You should use a version derived from the date only. This way, you >> >won't be in >> >trouble if upstream switches to git. >> >> I absolutely do not see why this should be an issue. > >well, you proposed a version like 'hg'. if upstream switches to >git, you >can't use a version like 'git' because it sorts before hg. I grant >you >that is easy to work around. If you deem it unlikely that two commits are made in the same day (which happens all the time), how likely is it that upstream switches VCSs and does an important commit on the same day? - -nik . -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSTDLdMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJZcSB/0Y0qa176+WM6I+lR+62QUY lEN9SW1gAAUpz5NV+1UJlqbgIz8VbxvHVEXcfAtVhYqVzYdQ6XLrbAHwAuQb7lKK ge7iV0GGLRlBJl97n9c5gqNMKCScEkVG4d1nDO4rn1o/7ghBfaz+yGlFt9woODQn ByDGB907Ng9fF7FrQ+rn+XH6ROI0OQBbDDNFTUEpst3lLoaVuMUxXUWQKimt0Kcq 6rVwhA5itJFA59zOufxME2OuUJe5surrfnhJApDZq2+Rzsy0E6PuwGCr8qtzepER B5uZ9BqVPEUj0UdMty9YreZnz2oNNUgifM2IKg7je5ZmVo7qsh10Opl1Y/68bkr4 =bC2y -END PGP SIGNATURE- -- 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/06c8759a-1922-4d0e-b157-feb9e165c...@email.android.com
Re: how do deal with versionless mercurial software ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >A packager is not required to serve users with such specific needs. Hmm, I last saw that attitude when being explained "the Arch way". I established an advantage for the user using my proposal - go get me a disadvantage for the packager. That said, what's the point in NOT being verbose? - -nik -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSTEDPMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJdszB/sFTL5LyhKjXavXzGRU7OdR 0Kp2yKKmShyGI+ElOmzF/1bDAD38UrQRJ+DvIYTLeLm3zJ51DeYA//svFKrKWs7J SDIuzUx6vGJgcDdEwxm2oY11emgrd9YDyVuRi06/b9kh7T0kff1jy/PxiAB4IMAm WVc5zH4+frgLlP3yw7pWwUZsfgXmJ6jOdHrX9SvupBF3FWtuZOi6ocwDI7wFZO8L ZbT97lUk7vSIB/BPwyhr2G8TAoQSnyUVp18Wtq8WKfJogX3IBjXwlE+hEqtICqGm 9cGQNTCKqkJEHcWsu1/ZQITw4qedFz/gRl3BxXorAbhIVMl6iZXirrGXqkOtsMSi =LX+C -END PGP SIGNATURE- -- 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/629e8051-c748-4f03-9218-6d683206a...@email.android.com
Re: how do deal with versionless mercurial software ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Vincent Lefevre schrieb: >Then, do you mean that VCS hashes are sortable? Of course not. One would have to do something like 0~MMDDnn+git in that rare case. My argument for keeping the VCS hash is to ease identifying the code in the package. -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSTqktMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJeukB/4gLywabqbqVA4ZA1xPxxM6 kZBdfisfn0WJn9ROGJEIYy47BYKKhLTpjZso1hKDUe8hT1/jdMewOp8mM7/WqGAg zmgKbBQT3S+DrVxvLxbl9H1n8yUR2pwkJNu/nq8dH2glNR3QJWyXwrzWlTs4mBTW zFS+dV7WQqYFInm/GTl/fM8nSHfNS4a1O9Xg7UyQCPbSnOxhbdKtD/yupDeSjs9G 536OW/i8v4hPbOxFNQloqGAZ54YGUt4pHDmHacxhWllYsAet3fe20yUqhzgeHJP3 1+9VPjRON06M1DgfeoBJUSVwWKQmdJBzhP4X/C2i0kK60tcf+ewDtukfE8Vwr8mO =7jDN -END PGP SIGNATURE- -- 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/f07e8cfe-fe83-42ff-8af4-a1082e16f...@email.android.com
Bug#726393: general: Possible malware infections in source packages
Hi, I have looked into this a bit. > Some of the source packages were caught on a gateway anti-virus scanner while > downloading. Using a gateway anti-virus scanner for downloads from the Debian archive seems a bit inappropriate, well, paranoid. Checking the signed hashsums would seem a lot better to verify the downloads; if Debian's infrastructure were compromised so viruses could get in *and* be signed, we and you have other problems. > http://ftp.fi.debian.org/[...] If you suspect an issue with the Debian archive, please test against ftp.debian.org. > I looked into one of these, libmail-deliverystatus-bounceparser- > perl_1.531.orig.tar.gz, and found multipart email file containing zip > attachment. Inside this archive is a .pif file (PE32 executable for MS > Windows) > which is detected as Win32.Worm.Mytob.EF. Yes, and the package carries it because it needs it in its operation. Have you read the README file? > This doesn't look like a false positive. It isn't a false positive in that regard that the package *does* in fact contain the virus sample. However, it *is* a false positive, as the sample is there intentionally, and no virus scanner can guess the reason why it is there. It does no harm in the location where it is, it will not spread, so is it in fact a virus? No, it isn't. > I hope that the source packages would be sanitized from any actual > malware samples. If a package has to contain virus samples for its operation, then how should anyone sanitize it? You just found one more reason why anti-virus sucks. (JM2C, I am not a Debian release engineer or DD.) Cheers, Nik -- Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Bug#726393: general: Possible malware infections in source packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marc Haber schrieb: >On Tue, 15 Oct 2013 13:19:38 +0200, "Thijs Kinkhorst" > wrote: >>I'm missing why the package cannot use the EICAR test virus signature >for >>its purposes. > >eicar.com does not have a distributable license. I do not think it is actually copyrightable software. It is a string that was agreed in to trigger antivirus scanners, so it is more or less a protocol. Consider the downloads at eicar.com reference implementations. TINLA, IANAL. - -nik -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSXnGVMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJX3/CACovs5UhI4gb9s02gWLzqL2 wC+wi+3ccQXJ91cnMUT+BSRHRjWRtvi/lC3cUYPzG1n1TNVzZDxIU5thdsg450Ok Eu0HhDGPoO8VrmC4LF8ygQsYjRRoKVM8JxOsRhFcyS7vxgfTdicfq7sAQ5sXKUEx Yl1uUGWgEKT5/6fP4+RF2lcvLVruJMj5+8Vv/1ryXBL0/tB78vZEl4h6pQkW98Oz vRBRL6JbfcUZ2GMOKs9d6pbpJxERv2pfq3TsP8o0Iu4Asb+AQ91PTpJCsy5I1h9G 5VMcctfvGjrjBY3AJJJU01AOlv801hRmsyebB0D1M9hZsbeQ56wf2lkymTVhIyCM =LkAR -END PGP SIGNATURE- -- 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/e1dfb869-8575-4346-b10f-deecac597...@email.android.com
Re: Bug#726393: general: Possible malware infections in source packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dominik George schrieb: >I do not think it is actually copyrightable software. It is a string >that was agreed in to trigger antivirus scanners, so it is more or less >a protocol. Consider the downloads at eicar.com reference >implementations. Looking at it as code, it is a 16-bit DOS Hello world-program. Not copyrightable, I suppose. - -nik -BEGIN PGP SIGNATURE- Version: APG v1.0.8-fdroid iQFNBAEBCgA3BQJSXnREMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJawsB/9AxDQcsOijrNCcesFuvZPT bmpopMgUvSpqE4m3tsIAw/MI7V8mk/UAOEJ2DANKl3xcZOEvdTILshgFMOEGObJD /u6qiF59nab3z2XrUnxiKijMn/0bDUSVSU/GRVJYRC8nCTvWuzqliTknDS3k5MpL fmpPQb28Sdc/JDayB4950KBxxFSNhKjGK7Th96NAiEmDjkN96L8KnbzRML9+Gk93 6hbGDnditAETvpWH1Y4EiNlrDAcCaH0/l+1b1Y8rdbnjKYVzhnOQmj8UxdweZLOV 5P/VlwzlLoQH99Fg6QcPRUBkooNbiVp730kDjzKbLBtirF3VkwdvgpbIfA8KTRXc =8U8Y -END PGP SIGNATURE- -- 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/33eb8d3b-b2ac-410c-82ac-68b903ac9...@email.android.com
Re: Propose Release Goals (delayed ;) - xz compression
Hi, > The only problem is that on small machines (things like the BeagleBone) > xz compression requires enough memory that you have to enable swap to > use dpkg. Now on a machine with a sensible disk this is not a problem, > but on a machine where the "disk" is an SD-card it is a disaster. correct me if I'm wrong, but it appears to me that xz compression has become the default in dpkg. With that in mind, won't this issue come up anyway? I mean, once a maintainer fixes a bug in a pckage and uplods it, the binries ill get xz compression. So this issue is in no way specific to making it a release goal. On the contrary, if we do it right now for the whole archive, users have something to rely on and, should it really be an issue, won't see their systems slowly failing more and more over time. That said, if choosing xz as default compression is harmful, then this harm has already been done and should have been prevented before making xz default in dpkg 1.17.0. I, for one, consider the release goal a good idea as for stable users, it provides a reliable moment in time when things will break so they can prepare for it. Still, I also think that in the first place, things *won't* break, as stated by others. Cheers, Nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Bug#726660: ITP: morse2ascii -- tool for decoding the morse codes from a PCM WAV file
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: morse2ascii Version : 0.2 Upstream Author : Luigi Auriemma * URL : http://aluigi.altervista.org/mytoolz.htm * License : GPL-2+ Programming Lang: C Description : tool for decoding the morse codes from a PCM WAV file This tool employs a volume/peak based method to decode the morse codes from a PCM WAV file as well as from text and RAW PCM files. . It contains some options for parsing abbreviations, prosigns and qcodes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQJOBAEBCAA4BQJSYEf5MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8paL9A//RFmI5OWznuuwQL6iwL+E HAkF1lDHRsyJsREevup2+bbhbZypvmwlpmChQy3ZbSH9X1SrQ81Nhmk3a7S7W7jo 8lqYItQv827DpCEYs7rWPjavh4pLdtKjWpG0Xg8gqsyzKodnkgNJA74Z2XQNJldP N/msFMFY8oVKp+qeK6+drC62UtoCmIZ2xkVePzYNn28hm5MCCiw769kssG3sCvGX dc/KVHTU7H7bH7++iCfc4W8Ar/yRb7n2xx1gXj6d8iNV9R1mOssKB3yyMD++yFNP c8NUQYxBioC+eQV4Z4RgUnR7oeNhBt1X7YdaeWJerOyog/6YH7hYj4QzPH+Y7S6s S0+tBsCZsFZESEOv0ru3VUmyr6ViYSFkRwc1SBDG0JgrRCAlVoWvePPh4vmGQqI2 JCsU185H0c6vgm5v4dpjwaaX4NusFrLWY004X5KJMRER7YHWvAsZVfqw+aoVWATw YBLHaCk7T5us3M/xFKGWovzeWyPv/n080J6Yr/JDTjWhSnS282cQkLwnJszbd/F3 1jmKF+Eh1VDyA/egfU/+34rj+CH84YJ7IuEjuL3TfBveZi6E6zw3WrFYu36G3lRr n/VirM5O7+CPvY6VDMVANPoOmSnw7py15VqkKlABK4Oh6YsU+K8nBbRSJ8mXBEur 3Wye6/uyXeAsoHnNVHL/5ZY= =4hW4 -END PGP SIGNATURE- -- 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/20131017202633.21683.86540.report...@keks.lan.naturalnet.de
Bug#726668: ITP: dtmf2num -- tool for decoding the DTMF and MF tones from PCM wave files
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: dtmf2num Version : 0.1e Upstream Author : Luigi Auriemma * URL : http://aluigi.altervista.org/mytoolz.htm * License : GPL-2+ Programming Lang: C Description : tool for decoding the DTMF and MF tones from PCM wave files dtmf2num supports any type of wave file (frequencies, channels and 8, 16, 24 and 32 bits), automatic optimizations (DC bias adjust and normalization) and both WAV and raw PCM data. . The program has been successfully tested with many audio files and moreover with those highly dirt and damaged, for example recorded with a microphone in a room or at a very low volumes or with some noise. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQJOBAEBCAA4BQJSYFlRMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pbvOg/+MoYhNopHEkd0vlBymIP3 e8wqRqR8QkCLXJgovJMKZhJlumbn0YZHO19Bc4XID/NimVgn2uPLjlS/bKn6oUzL lob+7RBzZYj9QIHqZmncZwZlFc+8RKBJC225D3bdWCyHkjGxSbwxVS6Ie6Xi+s9b WWGf7E7ifruuQhptCs0AMu0n3siFEtECYKWTPPsJfxZceiPisqEgI1F96tjdlDBa 6kNFasxxxRfY518f2ZNJ4B21Y/upjOvfdVqomh9Y9oCqN1ucFGRf4DDUogpHSeLk lBLkMXAGsdIbVyvh/pZ2O5dq6zPKPV4zvtJnrOHcrHKs7vC0K+EpfQT/Q887vvHV WkQl1aMcQvl6wDWomEAW8+OY56gvEwa20QoGC/YSshnoktTGThZjA7lUKwVVUN+b sJ5EBXAPolDpfbWkJIIO3KxMCAWB9qyIiyuxmkMnXdJpvVpljEJGOvtvWaMVbk7j SNNIbvSbhV3rr0E9NEOZp5DC7IutEiDk60shff+57Mr8nIgkUs53V3rBn9LHOkgB fM5cZ4ea0pAdkZ74kgd4clkvu+AMFLKwtwg49mOWxJOXqYhuNy38129P7r/NliIU UYkT3xhvRKhTvlPibltKnZdmNet2OlXdVRXkAy8kHSORMI21DDpJPhEQeJ3ouLx4 grFscH61l8psgeWTTDxf+UY= =0Doh -END PGP SIGNATURE- -- 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/20131017214033.6094.85012.report...@keks.lan.naturalnet.de
Re: Proposal: switch default desktop to xfce
Hi, > > * Does not depend on replacing init > > Wasn’t there some mention of xfce needing gnome-settings-daemon as well, > which would kinda defeat the point? Not as far as I can tell: nik@keks:~ $ apt-rdepends xfce4 | grep gnome Reading package lists... Done Building dependency tree Reading state information... Done 1|nik@keks:~ $ > And IceWM is a small, fast, usable default choice which will be familiar > to everyone who used a GUI computer in the last decades, except maybe for > the last 3-4 years when everyone went crazy over swish-to-do-stuff inter- > faces, phones, etc. As a matter of fact, IceWM comes, in icewm-themes, with a Windows XP theme :D. On the other hand, XFCE4 is more or less what GNOME used to be; it can, with some exceptions, be seen as a drop-in replacement for GNOME 2, but it sucks less than GNOME 2 ever did. I like IceWM as well, but XFCE is a good decision. > And then present Debian with all DEs, with the theme-du-release, to the > media, so that people truly get that Debian is the Universal OS, not just > “another GNOME ship”. Full ACK! -nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Proposal: switch default desktop to xfce
> > xfswitch-plugin -> gdm3 -> gnome-settings-daemon > > xfswitch-plugin is suggested by xfce4-goodies, so irrelevant for this > discussion. However, I must admit that even if the standard XFCE installation does not depend on systemd, it would be even worse if a user came along and wanted to extend their user experience by installing some XFCE addon and *that* would magically switch their init system. So, either systemd has to become the global default, while sysv-init *still has to be maintained, by all means*, or we enter another discussion round about icewm ;). -nik -- Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: Proposal: switch default desktop to xfce
On Fri, Oct 25, 2013 at 01:06:02PM +0100, Jonathan Dowland wrote: > On Fri, Oct 25, 2013 at 02:02:48PM +0200, Dominik George wrote: > > However, I must admit that even if the standard XFCE installation does > > not depend on systemd, it would be even worse if a user came along and > > wanted to extend their user experience by installing some XFCE addon and > > *that* would magically switch their init system. > > Installing systemd does not magically switch your init system. It doesn't *right now*, but from [0] I conclude that it would very much like to do so and so possibly, in the future, will. -nik [0]: https://wiki.debian.org/systemd#Issue_.231:_sysvinit_vs._systemd-sysv -- Wer den Grünkohl nicht ehrt, ist der Mettwurst nicht wert! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Bug#666527: ITP: ssb-sprom -- A tool for modification of the Broadcom Sonics Silicon Backplane SPROM
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: ssb-sprom Version : 20120331 Upstream Author : Michael Buesch * URL : http://linuxwireless.org/en/users/Drivers/b43 * License : GPL-2 Programming Lang: C Description : A tool for modification of the Broadcom Sonics Silicon Backplane SPROM The ssb-sprom tool allows for the modification of Broadcom Sonics Silicon Backplane SPROM data, e.g. the MAC address or the PCI IDs. This is especially useful if your BIOS checks the device IDs at boot as some vendors (Compaq/HP) do in notebooks to prevent the use of third-party hardware. The SPROM data is exposed through sysfs in Linux. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQHOBAEBAgA4BQJPdw1LMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQ2w6kvOIQdBKaJwwAkfaGLEEiceA8AiS6zV7p PY0u4T70WxytzHSpil8ItABsKD8dkY2qj/CeqCn0biRy+eHVqKm3HIEpnO4U7Up/ uAgS8kEax4U6B5mMQu1cIqmP9jq22HX7l4pwC09cDH1HjQbxfZ/hvejG+gBWUsyU JIOF5fMzZrd1AUTelGq8OJjK5MJ1kHyNJLzLTxSmj59sx3SCGCsUaw35WqREsqZ9 Yrg5c1aYJTAB09aQynvIZHUBfwUhm5RDsMPnAHIXGtZH1AkarriU4QMk57nSi+UB so0RCHdXmw1zOENUGALeXS5qoeXwUD5TgYDm+ls+f4MI3atNLeyqchhyuYo2vwSX fcbxSIV32bttAhXrBtQ+0Di17POptHhvyTqJPWagJ2W63efZ7RmMSZnT8jqJNH3B Im8aQ7iCDjcI5C/6qKdeiELcH4JAU95/ekrEzkBJOOPgesXAqeUSEMaTNgWZTIq5 3JBNyOqEFp+j6qdpUfy/7kufGruq2YKpjyLMzTjRPmM5 =kh+n -END PGP SIGNATURE- -- 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/20120331135733.8654.24804.report...@keks.naturalnet.de
Re: privacy-breach-google-adsense: how to get rid of it ?
Hi, > is there a proper way to get rid of the recent > privacy-breach-google-adsense Lintian violation/error report [1] ? obviously, remove all Adsense and related spyware fetching code from your package. Cheers, Nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: privacy-breach-google-adsense: how to get rid of it ?
Hi, > Obviously, but the problem is that the involved html pages correspond to > the manual of my package so it sounds not reasonable to wipe them out: > is there any tools that may help to clean up the corrupted html pages ? I assume there are Adsense images included from the HTML docs in your package. So add a patch to your package (e.g. with quilt) and have it remove the Adsense stuff at build time. -nik -- Ein Jabber-Account, sie alle zu finden; ins Dunkel zu treiben und ewig zu binden; im NaturalNet, wo die Schatten droh'n ;)! PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
Re: mupdf (Was: xpdf removed from testing?)
> I would love to have it *real* fullscreen >since > > f Toggles fullscreen mode. > >... but the rendered PDF remains in a small section in the middle of >the >window. Not sure whether this is a bug or a feature - but for >presentations ist seems I need to stick to evince. Or you continue reading the docs until you have reached the end. f sets the window to.fullscreen mode. H (Shift-H, mind you) fits the document to the screen height. I always use mupdf for presentations and it works just great! -nik -- 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/9ea74abe-3781-4072-8851-5fc1a57d4...@email.android.com
Re: mupdf (Was: xpdf removed from testing?)
>I also read this (I love that short docs) but there is a very thick >remaining gray frame - it seems the scaling is done only by integer >numbers which is for sure quick but the result is not what I want. Hmm. I cannot reproduce that, sorry! -nik -- 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/06747119-396f-4487-b492-48256e618...@email.android.com
Bug#736124: ITP: nxt-firmware -- Improved firmware for LEGO® Mindstorms® NXT bricks
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: nxt-firmware Version : 1.29-20120908 Upstream Author : Nicolas Schodet * URL : http://nxt-firmware.ni.fr.eu.org/ * License : LOSLA, MPL Programming Lang: C Description : Improved firmware for LEGO® Mindstorms® NXT bricks The NXT Improved Firmware is a community-based open source project around the original LEGO® Mindstorms® firmware for the RCX and NXT bricks. The firmware can be installed on the robot control bricks of types RCX and NXT. It is almost identical to the original firmware, meaning that all existing software working with the original firmware can be expected to work with the improved firmware as well. The main differences between the original firmware and the improved firmware are the addition of absolute position regulation for motors and that it can be built with GCC rather than the non-free toolchain used by the LEGO® Group. This package contains the firmware image file, which can be flashed onto the brick with various tools, e.g. fwflash from the libnxt package. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQJOBAEBCAA4BQJS3F3/MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYqBBAAozkMpwQUxXiZ46bfiMjm 9ntkP6FRMfjJPG5eOZlU71CjPNrAMtiWMN2CTVfFCfUb4BkupDXDrvuk2/QLE23s UVXB/VOrnfE6io6w7qFjX4/dMslImBbK05EBZvtLh6t/SelANjNnTlolAGRSxaOh +T2jtGUnt46HU5E381npXNVWikh5xfbNmuipGXJnAlKWpE5Dr+V0FgWKm7eV0/7n nfrX93/4IH4v4yG9R6dYBndLTy35CTc7GrmmfpYBfDOkQH+n373q2DjlRAPd3sYo MFJGIYgUijgiQX3iJew8cVqTKqcWiA34I37JYuZNHnkbaHzRhlc7ptALr1bbvtR9 V0KY2Bg9egFO9FPxhKPQQXiIwj52QYE9QEvex4Ad7VSadWe+gv8NVl1JPCpIboYn or9CK1AJQFz1M0iVzlAGuJ/wMYg70cLfVJFWOF/xYEZkwHcJc72dAFlTvIetmHf8 Hbshm20VgCkZtdoj1noZab2HmyuggGWr5NIr1jpDCH82rrK9bfke5b9zsvHHyMNU edtvwdg64MEvFfWErG6bwczHXAJ7AhMIzqLHFWe1y9MuH7MkAxvCa02x6XeQ9S1b jGT2ECWOQ4SRtZVk4XOP6wYAubfx5WnPeN08J32XxhVBcihsT9blU3DmgI6kvFzV xMbVlKyqWyPQGzJgwkjPVfM= =ny8Y -END PGP SIGNATURE- -- 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/20140119232145.29571.99490.report...@keks.lan.naturalnet.de
Re: Valve games for Debian Developers
>That's belittled out non DM/DD people that are contributing too (and >probably >at the same level...) ;) Then, obviously, they should apply for DM. Seriously, I think we should stop begging for more. Valve's (subsidiary's) offer is a very kind move and I'd not abuse that community attitude. JM2C, Nik (written as non-DM/DD) -- 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/a9bf328d-938f-46af-8a39-a603fb1b5...@email.android.com
Tired of my fellow SysV supporters
Hi there, I think we all agree that the init system discussion is far away from what is good for the project, under any political andsocial aspect. I don't like systemd either, and I do not like the decision of the TC, but what annoys me most is the attitude of some (too many) of my fellow SysV supporters. I do not know how many of them are trolls, but the content I had to read on this mailing list in the last days is clearly intolerable. systemd, be it as one init system or as the only init system, will not make me leave Debian, but what I had to learn about parts of the community could easily do so. Please, whoever cares about that, do not hesitate to remove those people from the project! Cheers, Nik -- * concerning Mozilla code leaking assertion failures to tty without D-BUS * That means, D-BUS is a tool that makes software look better than it actually is. PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 signature.asc Description: Digital signature
State of Roundcube packaging in Debian?
Hi, I found out today that roundcube was removed from Debian testing due to some unfixed bugs. I investigated a bit further and found that: - 1.1.0 has long been released upstream, but: - the watch file never picked it up, and - the package VCS is stuck at an unreleased 1.0.0 - A partially fixed package was uploaded to unstable in January, but was not unblocked, and - is not in the package VCS Could you please elaborate a bit on the state of Roundcube in Debian, and what I (or others) could do to get it straight again? Cheers, Nik -- Dominik George (1. Vorstandsvorsitzender, Pädagogischer Leiter) Teckids e.V. - Erkunden, Entdecken, Erfinden. https://www.teckids.org signature.asc Description: OpenPGP digital signature
Bug#782749: general: All browsers except Links2 crash constantly and iceweasel is broken
Control: tags -1 + moreinfo Hi, > All browsers I have tried but Links2 crash constantly. Often they will not > run at all. Please provide more detail about this. Which browsers did you try: How did you install and start them? What do they output? > I expect the browsers to work and not crash all the time. So do we, and I am very sure that this is what happens for most users. > I cannot install Chromium, and cannot install iceweasel or related browsers > as these packages are broken. What do you mean by saying that the „packages are broken“? iceweasel is a bit outdated, but existent in wheezy for sparc; Chromium is not existent for sparc, which cannot be called „broken“. -nik signature.asc Description: OpenPGP digital signature
Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)
Hi, > Note that the problem still occurs on an available set of packages: > just start with a Debian/stable system (jessie) and upgrade > libgnutls-deb0-28 to unstable (no dependencies/conflicts will > yield an upgrade of wget, which will occasionally segfault). well, then, obviously, the dependency on libgnutls-deb0-28 (>= 3.3.0) in wget is a bit too optimistic. This could have been prevented by the wget maintainer selecting a more restrictive set ot libgnutls versions, probably just 3.3.0. Then again, you wouldn't expect a library to break ABI between revisions. So this might also be considered a bug in libgnutls or even in its developers. In any case, this is nothing any package dependency system could fix unless told about the situation, because, as noted above, there even is an expressly written rule stating that 3.3.15, being >= 3.3.0, is perfectly ok, and that's what apt takes into account, and that's the best it can do. -nik signature.asc Description: OpenPGP digital signature
Bug#794468: general: no watchdog support in installer kernel
Package: general Severity: normal The Debian installer images for jessie apparently do not have watchdog support enabled in the kernel, so they do not send heartbeats to the BIOS. This results in the installer system aborting and the machine resetting after five minutes, or whatever the BIOS sees as watchdog timeout. Disabling watchdog support during installation is obviously a simple workaround, but it could still be enabled as to my knowledge, it does not make the kernel significantly better. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150803113739.16932.23668.report...@dgeorg-nb.lan.tarent.de
Bug#912226: ITP: shelltux -- interactive bash tutorial
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: shelltux Version : not yet a versioned release Upstream Author : Gregor Mitsch * URL : https://framagit.org/feinstaub/shelltux * License : AGPL-3+ Programming Lang: Bash, Python Description : interactive bash tutorial ShellTux is an interactive bash tutorial that leads through many exercises right on the command line. It collects many exercises fo command-line use, but also for stanrd X tools, desktop environments, etc. ShellTux is currently writte for German language users. I intend to maintain ShellTux within the Debian Edu packaing team. -BEGIN PGP SIGNATURE- iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlvXEI0xGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylrkjD/0Q7DNl GjxaXXE1RGTF3U8o8BYQActCpD+ml8rp4rHQqG1Mlme0uzwbqNRYIGezQ00ZSxR/ 2ijJ5yw2Nk8JZEeJ+5pYpF9syb5T4UHmEdClPsk+POEU+5KIGNrCZTRf+negiuzl YtZ2kxQqC1o2625Ox0U2pGX6LJM4A+r9BnojSxW2nnjImzD8WPvsY8mtkeBjv4tZ D+0KQxuQUNY9oPb8pTGol0oviaBo5b6Jf1kX0f6gWHLJrksT2UjXgX1/rc2I6bBY KW62Op/6UHw3xfEqfQimxF+cD0tmRQj8Pb2ik07eKEf241jLEQo0SluBmXWFWbPb VUDHBWKJ6mnnYBfN3wde4V82hAGJlKcmBPQK3B89/PxxUDshJVqy/2Tfj17TVwsP FrdIbLM4z/rRAbu0Ox6DgmJ4NiKyrPQ45FxVhBD9fbBSxxGj7kOTWY33fhGhm8tI aMINDKT9L32DlLk/hAmgcpZVWU9USzhf1sBVIYwdY81suljT3cVlsIZYrEgXFYmL 3iwg0ACuCDjIX92GKi2aqynATR7QSuwPDh2OQAfZIEu84doctP/GlSfReObITRSX /lcAqeSkhJwTzi59B6EgYBDJ2Rc90nZ8BYB8t1frsRBH2OTE2vMWtmJ27xaetQE7 JCY0H2/8p1WXRzVIszw9EI6EUiQ4nE628nIH5g== =M5t1 -END PGP SIGNATURE-
Mass bug-filing to move to python3-pygame
Hi, as the maintainer of pygame, I'd like to bring the move to Python 3 forward, and thus intend to ask all rdepends that are applications to try and move to python3-pygame. The packages are: angrydd ardentryst bambam bouncy bubbros childsplay deluge-gtk ffrenzy fofix freealchemist freevial fretsonfire-game funnyboat gameclock impressive krank lightyears magicor monsterz-data oneisenough opensesame pathological psychopy pydxcluster pykaraoke pykaraoke-bin pyntor pyracerz pyscrabble pysiogame pysolfc pysycache pyvnc2swf seahorse-adventures singularity slingshot snowballz solarwolf sugar-pippy-activity torbrowser-launcher whichwayisup -nik signature.asc Description: PGP signature
Re: Mass bug-filing to move to python3-pygame
Hi, >that is fine in general. Since Python 2 is supported in Buster, please >use severity: normal for now. Most of these games are considered to be >complete and/or no longer supported upstream. If we want to preserve as >many of those games as possible, we should come up with a plan how we >can port python-pygame games to python3-pygame. Of course. I even intended to go with wishlist for now - just making sure it's on everyone's radar so soon that we can actually find a way without hurrying. -nik
Re: I resigned in 2004
>But at the same time, I consider mine a very polite answer, without any >particularly accusatory wording or anything like that, nor I consider >any of what I wrote worthy of being replied with: >Fuck you. Do not contact me again. I shall consider >any further contact (from you or anyone else in regards to this matter) >as harassment, and I shall seek legal counsel. Exactly what I thought. If you come up with such directly insulting words, you probably are in no position to judge others. This reaction, to some extent, suggests that the person does not understand any other tone than what Mattia used. I am thus very happy that this DD is leaving immediately - whether you see this as bureaucracy or not, he agreed with rules and processes when he joined, he agreed with the CoC, and he deliberately chose to break quite a number of them. -nik
Re: I resigned in 2004
> > 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. -nik signature.asc Description: PGP signature
Re: I resigned in 2004
> 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. This is a valid argument - which should be used to change the CoC. Right now, it does imply that by using a Debian mailing list, you agree to it. -nik signature.asc Description: PGP signature
Re: Is using experimental distribution for shelter during freeze useful?
> Your thoughts? sid is not a rolling release for the public, it is a development area. Some users use it as a rolling release to get bleeding edge software, but in fact they become a developer that way (not meaning DD). If you think regular development prevents you from staying up to date during the freeze, install the packages you need from experimental. You are a developer, after all. -nik signature.asc Description: PGP signature
Nasty dependency/bug situation (with php-zmq, but applicable in general)
Hi everybody, situation is as follows: I have a package (movim) which just got accepted into sid, and used to work properly. It now turns out that it is broken with PHP 7.3 - or rather, php-zmq has issues with PHP 7.3 [1]. Now the situation is as follows: * The bug is in php-zmq, but only with PHP 7.3. * Movim does not work due to that, but only with PHP 7.3. * PHP 7.3 is only in sid, testing has 7.2. This results in: * Movim, as it is, does not work in sid. * Once Movim migrates to testing, it works. As the issue is mot with movim, I'd rather not mark movim RC-buggy to stop it from migrating. Of course, the first step is to mark php-zmq RC-buggy in sid by reporting the upstream bug with severity grave. But there is actually no reason to remove php-zmq from testing until php7.3 migrates. I could tag the bug as only affecting sid - would that prevent auto-removal from testing? But in any case, this would become incorrect the moment php7.3 migrates. What is the correct course of action in such a situation, where a bug is in package A, but only if package B has version (>> X)? Cheers, Nik [1] https://github.com/mkoppanen/php-zmq/issues/193 signature.asc Description: PGP signature
Bug#915387: ITP: ratchet-pawl -- Asynchronous WebSocket client for RatchetPHP
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ratchet-pawl Version : 0.3.2 Upstream Author : Chris Boden * URL : https://github.com/ratchetphp/Pawl * License : MIT Programming Lang: PHP Description : Asynchronous WebSocket client for RatchetPHP Pawl is a WebSocket client for the RatchetPHP framework. It can be used both as a standalone app, or as a library. While implementing the standard WebSocket protocol, it can best be used with ratchet-rfc6455, To be used in the next upload of the movim package. -BEGIN PGP SIGNATURE- iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlwFIKMxGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylmK5D/9xiG7F nPdtP5Go15zSE2tWMcseqDiq7Scr6y334xTXXqj8HXyn/cdlwLCWP/0P41KxR+7A WxU14lNI4F9jR5k5Q0cIEdXe3g++GfJk8elYY7LcfTcG3tZo00LOwrJROC7dZ+NL VGc7jK4PsroBsdFrKtHnYZj4rP+4gdtARkeNhOHYaYx/4n8gReZP++6wFH1oVrD2 JsHOnRR+BK+ppaTxtTK88KRTQmTcDcFVuTVz2iLXzKRx8tbH2DfH7fetN+aWuir9 i4Nlgtx0Mt9aW163VbiB38GIbxia1Y3b/frfLV+WEBQKa/MEr3E0q1XJ1RARuq4V OlbCQPs6y0u+ZHAZzd80FL35WRUZwmTQdel9P9mY06KfGtKv3xhxCcd0YhZUnTxd tFBBSR68NtGY4GsaUJPxdyCEQ4zCeyFD6JVwIk/u/NH9klxZcma1xLd6TuHm1hbM 2udf5+737EKnPWvTtmAZ9Pvr2OdyyYmFcji3/8+Pt4ALk8G35XFwl9UTUeJIqiTG L0/ClmDRUGaidOe/JilTOBLe/HNWTdlVRl6E3SuT/KhKRvgGKafO+KLTWa3TGv8N YK8nuJVIeQNbtWwaX5lxoofLjTK4fCNao2PjWQ3PqUXkm4G15hhjlvmrzsautI9B /ZDY6zNF7xDRnXm1+arWYfGpjiqPdSznw8LrgQ== =UwVF -END PGP SIGNATURE-
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
>> We had volatile, which, redefined properly, could help. I am trying >to draft such a definition. > >Did you get a chance to work on it? I do have this on my todo list for around Christmas. People who know me that I deliberately leave out the year, but my intentions are 2018 ;). -nik
Proposal: Repository for fast-paced package backports
Heisann, alle sammen, as announced in the recent thread about maintaining, I hereby propose a repository that allows making “backports” of packages available to users of the stable distribution, if those packages cannot be maintained in testing and backported in the usual way. If you are interested in what lead up to that, please see bug #915050. I will give a short summary of it here. Reasons for having a special place for some packages (You may want to skip this part if you are familiar with the situation.) As all developers know (but passers-by may not), for software to enter the Debian archive, it is always uploaded to the unstable distribution, then migrates to testing (hopefully ;)), which is at some point snapshot and made the new stable release. From there on, maintainers have two obligations: Firstly, keep the package in stable good and secure, e.g. by uploading security fixes for it once they become available upstream, or even backport fixes themselves. Secondly, provide the package in unstable with updates and ensure its migration, to keep it ready for the next stable release. Now, for some software packages, this process is problematic, because upstream may have another idea about software lifecycles. Concerning the GitLab example, upstream provides security fixes for three months for their stable releases. Backporting fixes from newer versions is very hard or impossible because the massive amounts of changes to the software in every new versions. This is something that also affects other packages, like Mozilla Firefox, which has a firefox package in unstable, and a separate firefox-esr package, with the ESR version of Firefox. Only the latter migrates to testing. Users of Debian honour it for its stability, but as an agile software lifecycle is adapted by more and more very popular software packages, not being able to install these packages in the trusted, well-known fashion through the official apt repositories is becoming more and more of a drawback. It can easily be assumed that the normal release and maintenance cycle of Debian stable will not change, which is very good, so we should find a way to still provide such software as described above to users. Why backports is not enough === This also is well-known, but for completeness: Formal backports in stable-backports are required to be direct backports from testing, and are a stepping stone within the upgrade from stable to stable+1. Thus, a version of a package that is not in testing can never be in stable-backports. Name of the new repository == In the past, the name “volatile” was used for a similar repository, but with a different scope (limited to data packages for things like virus scanners). I will thus use the working title volatile throughout this proposal, although this may change. Other ideas: fastlane, unsupported (Please feel free to add other ideas.) Requirements for a package to go into stable-volatile = The new volatile proposal is not intended to ease life for package maintainers who want to bypass the migration and QA requirements of the regular stable lifecycle, so special need must be taken to ensure only packages that need it go into volatile. I want to summarise the requirements like so: - The package must be maintained in unstable, like every other package. - The package must not be in testing, and care must be taken for the package not to migrate to testing. - Regular maintenance for the lifetime of stable must be impossible or unnecessarily hard, and this requirement should be assessed in a verifiable manner, e.g. referring to upstream’s lifecycle model. - There must be notable need for the package. Like for backports, user requests might be an indicator. - Should the package be removed from unstable, it must also be removed from volatile. - Should the package begin to migrate to testing again, it must be moved to stable-backports. Before starting to maintain a volatile package, the maintainer shall seek consent (or doubt) on debian-devel. Building packages and package dependencies == Packages for volatile are built the same way as formal backports, only that the source is taken from unstable rather than testing. In particular: - Changes shall be kept as small as possible. - The package is rebuilt against stable. - The package may depend on packages in stable, stable-backports or stable-volatile. Dependencies on other packages in volatile should be avoided if possible. Especially, dependencies of the package that also need backporting must not be added to volatile just because they are dependencies — every dependency that is needed to be backported to support the volatile package must be considered on its own and in all but unprobable edge cases be maintained as a formal b
Re: Proposal: Repository for fast-paced package backports
> We already told you to build your own repo. You should probably start with identifying the senders of mail correctly ☺. I am not the gitlab maintainer (and will never be). > Imho you should start the same way backports started - outside of > debian. > Prove that it works and integrate into Debian later. I would agree with you if it were a big change - however, the proposal has a very low impact, if not none at all, on existing stuff. In contrast to what you seem to believe (accuse people of…), this proposal is about helping Debian as a whole, not forcing a certain package into the distribution. gitlab only serves as an example of why it is useful. The Debian infrastructure already supports everything that is needed to implement this, and starting with parallel infrastructure would probably mean that it will fail because this requires a single person spending time and money to maintain the infrastructure (which is otherwise already there), and to make it really work, this is a low (think of buildds, etc.). In any case, I do not see why you would fight the fact that someone makes a detailed proposal. A proposal can be accepted or denied, of course, but your tone implies you think noone should have made the proposal i nthe first place. Please don't fight people wanting to help based on your opinion about a prior case around gitlab. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Tue, Dec 25, 2018 at 10:11:43PM +0100, Alexander Wirt wrote: > https://lists.debian.org/debian-backports/2018/12/msg00028.html > > This wasn't about gitlab. Oh. I must have misread the "gitlab" in the subject, along withthe mail being sent to the gitlab maintainer, a gitlab bugreport in the BTS, and concerning a request to accept gitlab into backports ;). Still, there's a big difference: * The thread you refer to is about uploading to backports. This proposal ia about *not* uploading to backports. The newly-proposed section is only intended to co-exist with backports, and interact nicely with backports. (Mind the difference between backport as a general term for a package made available for an older distribution, and the name backports for a section in the Debian repository). * Your mail you are referring to talks about "backports" from unstable being a different workflow - this proposal proposes such a workflow. * Your mail refers to packages being indistinguishable in -backports - this proposal is all about having a new section in the repository to distinguish them. In short: This proposal addresses the exact concerns you raised before )although I am not the person you expressed them towards). -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
> In short: This proposal addresses the exact concerns you raised before > )although I am not the person you expressed them towards). Well, sure, I was involved in that thread, but only in the way that I announced a proposal (this one). Not in any of the stuff concerning adding something to -backports. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
Hi, >having read the whole Gitlab discussion, I still don't get how/why the >new repository depends or relates to backports. Instead it could be >self-contained, except for stuff already available in stable. Couldn't >you roll the new repository entirely independent of any backports? Even >if you say there won't be any additional work for the backport policy >owners, letting a new repo depend on backports will implicitly have an >impact, which doesn't sound fully thought through yet. This is answered in the proposal. The reason is to not have volatile abused to ease backporting, and to allow packages to easily move back to backports again. >I consider especially copying parts of the version scheme fairly >confusing. This gives your concept a bad touch of just trying to work >around established rules (i.e. backports rules). Instead of defining >such minor facets I would recommend you to work on clarity about what >rules you want to establish in the new repo instead. I am a bit disappointed that my efforts to emphasize good compatibility with established processes is interpreted that way. As I already laid out several times during the last days, I am in fact disappointed that assuming bad or egoistic intentions seems to have become normal in Debian. That said, the version numbering is a way to ensure work *with* established rules, not around. >Also, as Alex suggested, I would prefer if such experiments could be >started outside the official Debian archive, like backports once >successfully did. Given how much efforts it took to get backports >integrated officially, I don't consider adding a new repo a minor >change. Did you discuss your idea with ftp masters, dak maintainers, >and buildd admins before? I did not discuss this proposal before discussing this proposal, no. That's why I am discussing this proposal :). If you read it properly, you will find that does not add anything really new, but extends something existing - yet without interfering with it much. >I acknowledge that Debian needs a solution to support fast moving >projects like Gitlab better than now. Yet, without a *proof* of concept >how this could work out in the long run (i.e. across more than one >Debian release cycle), I don't think it is the right time to ask for >such a big change now. Again, the change is not new - it is an extension of backports, using the exact same concepts and rules, apart from the source distribution and the target directory. It is an extension designed to play very nicely with backports. > I consider Debian open enough to support such >concepts outside the official archive first. I hope that e.g. official buildds will not grab code from my private machine and build it, for example. -nik
Re: Proposal: Repository for fast-paced package backports
Hi, I like the general direction, but there are some aspects of your >proposal >which should be improved. Thanks! >> Other ideas: fastlane, unsupported > >Or maybe something like "fastpaced", after all this repo would not be >unsupported at all, the very point is to provide actual support after >all. I actually think volatile is a good name. After all, it's not so far from the previous volatile. >> - The package must be maintained in unstable, like every other >package. > >Given the nature of the packages in "fastpaced", it's counterproductive >to mandate the same standards as for the standard archive, it rather >makes >sense to relax some aspects. > >E.g. we usually try to avoid embedded code copies. But for a package >like Gitlab that doesn't really add any value, if an embedded Ruby >package is affected, Gitlab upstream fixes it in their weekly release >anyway. And if not using the embedded code copies you'll end up with >plenty of >dependencies which can no longer be fulfilled from stable as upstream >moves forward. The intention is to keep the way open to have a real backport again should the situation change. I find that very important for compatibility and assuring upgrade paths. >> I propose to add the volatile repository next to the backports >> repository, and treat it as part of backports. > >I wouldn't tie this to backports at all, rather make it a separate >section of the archive and have some ACL mechanism to allow the DDs >maintaining a fastpaced package to grant access to it (similar to >#817285). I am open to this, as long as the goals to have full compatibility with backports stay the same. -nik
Re: Proposal: Repository for fast-paced package backports
>Just to make things a bit clearer for people who may not have followed >some of the discussions on d-bp-users lately: the point is to be able >to >support fast-moving software with not-so-fast moving dependencies; >the dependencies may easily be backported without too large a burden >(their versions will not come too often, so they will be able to >migrate > to testing and thus fulfil the criteria for being in backports), while >the main piece of software moves too fast, including across major >versions and with incompatible changes, so that it is not suitable for >being included in a stable release (thus the part in the proposal about >blocking its migration to testing). > >The maintainers of the stack will first package the dependencies, wait >for them to migrate to testing, then backport them, and then they will >upload the main piece of software first to unstable and then to the new >suite under discussion. Exactly. And the result shall still have the same quality as any package in -backports, technically, as far as it can. Thus the requirements for version, etc. Volatile is not to become a place to dump packages to bypass -backports. On the contrary. -nik
Re: Proposal: Repository for fast-paced package backports
Hi, >I would, however, completely separate it from backports. I.e. > > - separate NEW queue > - different suffix > - no need to keep a volatile package out of testing > >Why? > > - volatile is a different beast from backports, this should be > very clear to both package maintainers and our users The idea is to have them separated, but fully interoperable. I.e. the proposal ensures such things as: - foo is not supportable for the buster release cycle. It goes to volatile. - foo becomes supportable for buster+2. - foo is backported (as in -backports) to buster+1 This will work properly, among other such scenari. > - volatile must not put any burden on the backports team, which > e.g. a common NEW queue would probably impose The whole point is that it is not new work or a new burden. This is one reason for the rules being almost the same and the clear decision path and movement between -backports and -volatile. A -volatile package is handled exactly the same, except it comes from unstable. The workload is the same as if the package had migrated to testing and was being uploaded to -backports. The defined preconditions ensure this is not abused for a ton of packages. -nik
Re: Proposal: Repository for fast-paced package backports
> - no need to keep a volatile package out of testing Oh, and yes. Having a package in testing means it will be supported for a stable lifecycle - a full contradiction to volatile! -nik
Re: Proposal: Repository for fast-paced package backports
>> I actually think volatile is a good name. After all, it's not so far >from the previous volatile. > >volatile is a very bad name for this because we've used it already for >something else. Well, I consider it more or less the same basic idea. The old and new ideas have more in common than not, with the only difference being that previously, volatile packages also had versions in stable. -nik
Re: Proposal: Repository for fast-paced package backports
Hi, On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote: > (Can we keep this on one mailing list, please? /me restricts this to > -devel) No. This has the potential of keeping people who are directly impacted by this proposal out of the loop. > And besides that, I think the more universal answer is > bikesheds/PPAs/you-name-it instead of yet-another-suite. Absolutely not. It might be an answer, but to an entirely different question. This proposal is about providing packages under the same rules, policies and QA as any other package in Debian, built in the same trustworthy manner. This is something a PPA does not do. To stay with the gitlab example: I would very much like to see some people (including the company I work at, two organisations I am otherwise involved with,…) use packages from Debian. This is mostly about trust - it is a very useful policy to limit the entities to trust for software distribution if you run production systems, especially when they handle third-party data. Debian is such an entity - while there are many people working in it, it is a body with defined procedures and standards that can be relied upon. Debian telling users to add a PPA to their trusted entities that is managed by some person alone, be they a DD or not, defeats this entirely. On Wed, Dec 26, 2018 at 08:29:17PM +0530, Pirate Praveen wrote: > The -backports team does not want the dependencies of gitlab to be in > -backports even though it meets the criteria for backports. So we will > end up adding it to volatile. Now if some one else wants the same in > -backports, they will have to repeat the process. > > Take nodejs or npm for example, which I backported now. In buster the > -backports team does not want it in backports if I'm doing it for > gitlab, even though they satisfy the requirement for -backports. So we > will end up uploading these to volatile, if someone else wants it in > -backports, they will have to do it again. > > It is one way (volatile can use -backports, but -backports can't use > volatile). I'm fine with that if people don't want our work for volatile > not added to -backports. > > Dominik, > > I think we can go ahead with volatile as separate suite and take > packages from -backports if exist but add all new dependencies to -volatile. > > This, > > "Dependencies on other packages in volatile should be avoided if > possible. Especially, dependencies of the package that also need > backporting must not be added to volatile just because they are > dependencies — every dependency that is needed to be backported to > support the volatile package must be considered on its own and in all > but unprobable edge cases be maintained as a formal backport. Obviously, > the unprobable edge case occurs when the package depends on another > package that also fully qualifies for volatile, as described above." > > should be changed to, > > "Dependencies of the package that also need backporting must be added to > volatile." No. The dpendencies of gitlab not being accepted into backports right now is an entirely different issue. I am repeating myself: This proposal is not intended to ease the life of maintainers whose packages qulify for -backports. The only difference between -backports and -volatile in this draft proposal is that -volatile can take packages that are not in testing due to the exact one reason that hey have a shorter lifespan. No single other thing qualifies a package for -volatile if it is not qualified for -backports. If there are other issues to solve than the lifespan of the package version, they must be solved in another way. On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: > As I said, gitlab was not about manpower. This new repo is completly against > our vision of what backports is. Therefore we don't want it within the > backports suite. Alexander, please don't get me wrong, but have you read the full proposal by now and considered it, independent of the gitlab story? I am pretty certain you did not did that yesterday before starting to object it - not because of your argumentation, but because reading, understanding, considering and challenging it and then writing your reply is simply not physically possible within the 4½ minutes it took you to object to it ☺. Therefore, I ask you to bring up the points you think are against your vision of backports. In fact, the proposal is laid out in a way that explicitly does *not* contradict it, and I am wondering what makes you think it does, let alone "completely". I still got the impression you are also confusing me with Praveen, to the views of whom I do bject as well to some extent (see above). So, this proposal is about extending -backports, but without getting in its way, and following all its ideas except for the source suite. Thus, please let us discuss this in a well-founded, argumentative manner instead of just ruling it out from the start. Thanks, Nik signature.asc Description: PGP sign
Re: Proposal: Repository for fast-paced package backports
> I don't want backports to contain things are are not suited for a > release. That's why we are doing all this. It is NOT about anything to backports. It is about adding something new that uses the same RULES as backports, with a slight diversion, and thus can also make use of infrastructure already there for backports. Neither being economic with manpower and machines nor trying to be a good neighbour by adhering to the same rules means to change or add anything to -backports. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
> >If there are other issues to solve than the lifespan of the package > >version, they must be solved in another way. > > I agree with you, it is the best outcome. But when people with power > (-backports ftp masters) are not willing to consider it, we have to go > with plan B, which is less than ideal, but can move things forward. Plan B in this case are PPAs. If you want to engage in that idea, please do separately from the -volatile idea. > >> As I said, gitlab was not about manpower. This new repo is completly > >against > >> our vision of what backports is. Therefore we don't want it within > >the > >> backports suite. > > > If people argue both ways, how can we answer? Either it adds more work > for -backports team or it does not. Some people say its not fair to > add more load while ftp masters say its not about load. As Alex laid out, it's mostly just the -backports team handling the NEW queue. So all of this really is independent from -backports, if another NEW queue is added (which I do not think is the best idea, but still possible). But, I do not think it is possible to start -volatile completely independently. I am pretty certain there is enough man power to handle it as a new suite, but on the other hand I am also certain there is not enough manpower to operate a compelte set of seperate services for it. In any case, I propose we stop discussing the who and where questions for a while and concentrate on the what and how. I will collect the opinions on that, and in a week or two, incorporate them into the proposal, along with the different possibilities for implementation. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
Hi,
> 2. I am happy with the current charter of backports and I think it's
> possible to move forward with fastpaced without having to change
> that charter.
Yep. That's exactly why the proposal changes nothing about -backports. I
am still confused why Alex and you keep insisting that anything would be
changing there.
> 3. formerer is speaking from experience when he says that it's
> possible to make this kind of change unofficially first, learn
> from it, and thus set the groundwork for making it official.
>
> If you foresee obstacles to that, can you say more about where
> they lie? Maybe we can help address them, or maybe we can find
> another way forward.
>
> If you don't see obstacles, why not start today?
I think I already made those obstacles clear: Starting outside means
buying, installing and operating at least a server vor
volatile.debian.net (or whatever you call it), setting up and
maintaining an upload queue, the queued, and everything around it,
building from source for at least the most important architectures on
hardware that needs to be there and maintained for that, etc. There are
several issues with that:
- It costs a lot time that could better be used elsewhere.
- It costs extra money, which I for one do not have to spare.
- I do not sure I can do it right, because I do not know all the
technical details.
Thus, because the change as it is proposed has such a low impact on
anything else, I consider doing all that over again unnecessary.
Don't get me wrong - I would not hesitate to go through it if it were
for anything that could break things, or make life harder for others, or
something like that. I am just putting the impact of the change and the
resources needed for seperate infrastructure in relation. Everything
about this proposal ahs already been tested when -backports was young
(thanks for doing the work!). This proposal contains nothing new to
learn, neither technically nor policy-wise. It works the same way
backports do, with the same considerations, except for the source and
target suites of the packages.
If you know how to start with a new service at
{volatile,fastpaced,whatever}.debian.net without having to reinvent the
wheel for acceptign uploads, getting packages built, etc., please
enlighten me.
-nik
signature.asc
Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
> > - The package must not be in testing, and care must be taken for the > > package not to migrate to testing. > So what would a user of testing do? Will there be a $codename-volatile[1] > suite for testing users? Or would they directly install unstable with no > other pre-release staging ground? (Which seems like a bad idea.) The testing distribution and this concept contradict each other. The testing distribution is the least supported stage in the Debian release cycle, and if used, shall only be used for testing the next Debian release. Especially, there are no timely security updates in testing, neither by the security nor by the maintainer. So using it for anything other than testing the next Debian release in a laboratory is a bad idea. This proposal, however, is about providing fast-paced software as an exception on an otherwise stable system. So if anyone wants to test fast-paced software within a Debian testing system, they should use the package from unstable, yes. (Having testing on a system without the sid zources is close to impossible outside the freeze anyway.) > > Similarly what are the constraints you set for upgrading, if any? How far > back will upgrades work and how current do users need to keep their system > in order to still be able to upgrade? For one, I think you will need to set > expectations here towards the maintainers if a package is never included in > a stable release, as they get very muddy otherwise. Plus you need to set > expectations for the users as the next package (maybe not gitlab) might come > up with requirements that upgrades need to go through every version on the > way to, say, update the database properly. And that's hardly supportable > unless everyone knows to update quickly. That certainly is something maintainers need to care about. (I consider a software not supporting skipping versions on upgrade a bug, anyway.) But most importantly, this is nothing that is specific to the -volatile proposal - it is the same for regular backports. So discussing this general backporting issue should not be mixed with the discussion of this proposal. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
> - Should the package begin to migrate to testing again, it must >be moved to stable-backports. > > - Using the same ~bpo version namespace Both of these poitns are there to *not* change anything about backports. If a package stops qualifying for -volatile, and starts qualifying for -backports, it's under the backports realm again. I consider this very important so it is very clear for maintainers what -volatile is for - in particular, *not* for bypassing -backports limitations. The sharing of the version namespace is partially a direct consequence of the previous point. > - "treat it as part of backports", which I assume means that >backports users would automatically consume this repo No. I see where the misunderstanding comes from - that's not what I was intending to say. -colatile is intended to be a compelte separate suite, that users can add to their sources.list separately (if they do, they also need to add the regular -backports, however). The rest of what I meant as "treat as part of" is adhering to the same rules, standards, etc., and re-using existing infrastructure like the NEW queue due to that. Also to ensure that the qualification of packages for either -backports or -volatile is clear and inforced. > > - new binary uploads to volatile have to undergo the >same NEW queue as backports This as about sharing resources and enforcing the same rules (except for source and target suites). The proposal is still possible without sharing the same NEW queue, but the first two points are a major concept ensuring that it will work. It will not work as well when removing them. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
> For backports the general supportability assumption is that you provide a > sane upgrade path from stable to the backports and from the backport to the > next stable (optimally the same package). Once you take the presence of the > stable package out of the mix, it becomes weird. How long do you need to > preserve compatibility code? How does an agile package that does not fit > Debian's release cycle cater to these requirements? This is wrong, at least in a big part. The stable release cycle does not apply for -backports. A package in -backports can be udpated an arbitrary number of times during the development window of stable+1, leaving us with the exact same issue as you are describing for -volatile. If you take into account edge cases, where a package is removed from testing during the freeze, is removed from -backports as a result, is not released with stable+1, then gets fixed and reintroduced to testing and -backports, it gets even closer. In short: This is a situation every maintainer has to take measures for, be it in -backports or -volatile. -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
Hi, > How to handle upgrades from stable to stable+1. Packages from backports > upgrade with no issues as stable+1 contains the same packages already > compiled for the stable+1. As long as the package is in -volatile, it is not in stable+1, and upgrades are ensured by the volatile maintainer. If the package is to go into stable+1 again, ist must move to -backports (see original proposal for details on that). > How about LTS? As stable-rolling repository would be usable in > conjunction with stable-backports and stable, would then > oldstable-rolling continue to roll or just freeze in place at the moment > when the stable becomes oldstable? I think oldstable-volatile could keep rolling if the maintainer wishes to do so, but must never be newer than stable-volatile, of course. Upgrades between oldstable-volatile and stable-volatile must be ensured by the maintainer. > Continuous delivery development model based upstream applications are > not quite a good fit for a stable release distribution. Maybe that's why we are drafting a mechanism to support them outside the stable release distribution ;). -nik signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
Den 27. desember 2018 12:30:33 CET, skrev Holger Levsen : >On Wed, Dec 26, 2018 at 11:37:21PM +0100, Dominik George wrote: >> As long as the package is in -volatile > >FYI: as long as this proposal is been presented with the name -volatile >it's dead to me and saves me from reading mails in this thread. > >Please try to listen if you start a discussion. If you confuse "discussion" with "immediately do what I say before anyone else gets the chance to say something", it's probably better if you ignore it :). I will respect your opinion and incorporate it in the next overhaul, but I have no obligation to "listen", as I am not in a lecture or otherwise under your education. -nik
Re: Proposal: Repository for fast-paced package backports
> Basically you would like to build an architecture equivalent to Ubuntu's > PPA No. Please at least try reading the thread first - it was explicitly explained several times that this has absolutely nothing to do with the idea of PPAs. -nik signature.asc Description: PGP signature
Bug#920896: ITP: python-asttokens -- annotate Python asbtract syntax trees with with code references
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-asttokens Version : 1.1.13 Upstream Author : Dmitry Sagalovskiy * URL : https://pypi.org/project/asttokens/ * License : Apache-2.0 Programming Lang: Python Description : annotate Python asbtract syntax trees with with code references The asttokens module annotates Python abstract syntax trees (ASTs) with the positions of tokens and text in the source code that generated them. It makes it possible for tools that work with logical AST nodes to find the particular text that resulted in those nodes, for example for automated refactoring or highlighting. To be maintained under DPMT. -BEGIN PGP SIGNATURE- iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlxRiK4xGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylvzdD/wNVTcy 6DAMI6U8cxNHkutosrA3nDZkZGetdyM8cHgNWq07F+4KlMIeqU08k9qZxi/KCWyQ LYORPAAn/9Lx8rwC0pZZPdhMKQGhQNz1F/Nr3xCf4RqoytczyP78NuV/K0+mteeX QKH0aFntxdhkZNfB6u/Uul4iL6cxs1H/b8KXdGGdfyDsBGJie0IeelS7cmM6WflZ Zel5mpjMoWBDUhdlmB6MZ8oNT3POmUCh24xZ/yuf0vQqlWmVxnhoZzDymsRQGIlt KymGM8jeZckF+76c6YXHuyGixTTr7t2IIwmk/WcwSWqIJnAYvnbKi/v4ZhL50/6H olEpRTUVZF1GnyeEahKtMYkecK8RaOE/VL16d++C2bjOi4q5gb7VQ6od40kyog69 IsB6W4Ibw0N5r1wkwg01eAIbWb6pxLiwPB/CWLSrpiHncMBKyrhiV8E4k/2/fUWd L4RWpZ2v69Vlmx02bTeAPiclZR+UfLjd0zzSwiQ5rplUkAFANBV0qvLI2Xg0aY5L 7P4f5MNDc2SlLSUq12XK+71AXhFebBja7U77cN3pULE8C+0PDMf/C7E58tijqA+N PHe+p62e/5V0aUcWY7d/NE2XjZNZ4q+7ob0dpDmgv6eazGTkb7d5cOJw6Y7BdhnB ipTGFDgLqpGvI28fPOG270pcTKp8ZAfN8LX4vQ== =hTkP -END PGP SIGNATURE-
Report from Debian BSP at tarent solutions GmbH, Bonn
Hi everybody, here is a short report from the bug squashing party, which took place at tarent solutions GmbH[1], Bonn, Germany, the last weekend. It was poartially sponsored by tarent solutions and partially by Teckids[2], with tarent sponsoring rooms and drinks, and Teckids sponsoring network and food. We had a very nice weekend with ten different people attending, including two new contributors from Italy (one of them from Tarent in southern Italy - nice coincidence, if you followed closely ;)). I am very proud that we managed to have a, form my point of view, very good balance between -project and -devel work, and also socialising. The two perosns from Italy got to know some of our tools, and fixed their first two bugs, and concluded that they would invest some more time into Debian in the future. I also spent several hours in the kitchen, creating more or less creative food (called "live catering" by one attendee) troughout the days ;). I very much enjoyed this . Now, coming to the technical stuff: It looks like we touched 38 RC bugsthis weekend, which is close to an impressing 10% of all RC bugs in buster atthis time. To be fair, we merged a lot. The bugs that remained at the end are listed at [3]. Here are short summaries: * Paolo and Thorsten made a lot of packagres build their documentation again, after a bug in a TeX package broke doxygen. * Christoph fixed a legal issue in a row of netkit-* related packages, which contained stuff without accompanying source. If he really uploads, we are sadly losing an important BSP running gag ;)! * Antonio and me fixed an issue installing freeipmi tools due to incomplete default settings for service startup. * I fixed several bugs in sssd which made it fail to build. * A row of test failures due to minor changes in dependencies were fixed. * Python packages installign header files to wrong locations were fixed in a row. * A SEGFAULT in midori when editing proxy settings was fixed, and sent and applied upstream. * Other stuff I failed to list here. We also had two people attend looking for inspiration for their own BSP, and we are now expecting another BSP in Germany at the beginning of May ;). As the main organiser, I want to thank everyone who attended for making this weekend so great. tarent, Teckids and me were very proud to be your hosts, and are looking forward to welcoming you on board again ☺! Cheers, Nik [1] http://www.tarent.de [2] https://www.teckids.org [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-rele...@lists.debian.org;tag=bsp-2019-02-de-bonn signature.asc Description: PGP signature
Re: Bug#924270: O: keepassx -- Cross Platform Password Manager
Hi, > 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 I am currently involved in evaluating password managers, also a +1 from me for dropping keepassx. -nik signature.asc Description: PGP signature
Bug#927225: ITP: upass -- console UI for password-store
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: upass Version : 0.3.0 Upstream Author : Chris Warrick * URL : https://github.com/Kwpolska/upass * License : BSD-3-clause Programming Lang: Python Description : console UI for password-store upass is a curses-based (more specifically urwid) interface for pass, the standard Unix password manager. It provides a simple, but powerful view of the password store and can copy passwords or extended information to the clipboard interactively. -BEGIN PGP SIGNATURE- iQKJBAEBCgBzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAly14TExGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylruVD/0a2MSd 3KAHkhTr7auO7bmMxiFl4iV1T8Zoa8PLT1qxqh2SfqiDmQgoO4zSu+fwirrTZuMw vnZ6HubLr7hcJmI+SIhnb4935JZqj0x5G0xFP5F0XT5wlnsYtOerHLXZZxAD7gYU PbxkpGqq5BOp2mPL/zcf6XexaJewVA+w/vrDhb/8kzjjKRtKL5TPcEmN0NfNqX3y jFJlYPfYp3LwuphdUF1NptQQGDmCIVqb49TiD72vjR6yAUpxNDb66nyGtm0KvTtb cpMVn24uHtzLYm49x2S6uY6d4E9j3/alxOFYpaCq2OLBhUfSdGANgTwYFThkcNlc sEfq4ePPcJrJC6vUyUk9Xm6mtB6c+/m4OGeBL3gb3thd6aH8FAEdZdb3viSogi+r okgdSwcVW1M7fw8/SAUPW3rgdtciJgBsMv/Hu/Kgzoxuozv4pUd1SNTo6KT6rNAQ 2EGjVizRLz/1sCG9xhFjA6yq5ecHWRHg0XcRgT2xIYWfuZQWCipq0dBdpapjUnzV zMmMTdan6TvM/3E0EYDVfoUQqtQNjz3aLwu3tTYUvCI9jTm0XfRJZaZH5J3YIrCy SXEGrbc2q5eaO9YhSzU29xvuWkJ7IYtK6uj5XWwGj+EESgYrq2NGX0ruDFWxeCot czplsiOyUUBPXRh2pHZVzK//au0X1LdjXeTOkQ== =St5s -END PGP SIGNATURE-
Re: Suspending Offer to Reimburse Expenses for Attending Future Bug Squashing Parties
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, > I'm hurt reading your message and Holger's. > I wrote to the project saying that the current situation sucked for me. > I got some great offers of help and I think this issue will be easy to > resolve. > > But then I got a message from holger and agreement from you that > basically said "if you did things this way it wouldn't suck." Neither > of you took the time to understand what my concerns are. > You just assumed you knew what my frustration was without asking and > jumped to a solution without actually considering the things that are > important to me. I do not think that this was the intention, at least not as I read it. While the way it was written sure can be interpreted that way, I somehow can see indications that the tone was i nno way related to the topic. Maybe to the bar in the MiniDebConf basement; at least right before I read that mail I saw a very tired Holger stumble by ;). In any case, I think the point here should be - and this, I support very much - is that we should make the process more open for non-DDs, that is, contributors new to Debian (but of course that can be somehow verified as having the true intention to contribute something, and in a way that, for starters, "getting to know some othe rcontributors" can be valued as a contribution in itself, to grow and strengthen the community). tl;dr: let's take the chance to make the community as open as possible (ideally, providing good mentoring at the same time). That, of course, does not rule out any other ideas and concerns on top of that. Cheers, Nik -BEGIN PGP SIGNATURE- iQJlBAEBCgBPFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlz8I7UxGmh0dHBzOi8v d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYwAKCRC3mjwW oMTyluppD/0dFc3TvSmXbhWfV78ugKkTTLNo/0MWTpLx2qvk2V0KNm98+MxL+vBZ hsSKsc2zYcg1Gl9gkf/9QYtxHAmz/VLm97AfMzHC1KEU+i6LDJ2ltU8EXMjC++zh Dn5EwZHCES0zM3qRCm7J6d0HT6EX9aarqqfqzwuaCmHT3zkrRn30oaxZ2IAWQZ3A kLyG88f+9oyIr6EfFv7+9q/9gcNfphqY621CxLeFAXDG5m5w+uzu3taLsoOMDVWM hSiVrHPBeUIe7hv0dAmbD0CyaaqWqBD2bekOUNJCumsW4z7c1Kt1WYHTIMGqCJ9i vh7eRsEd7Nv8BrqZEgPwUe8Xtp2ca6SOGcsjIZcnGuIydZobwEyd6as/ns1h Vq+o+hoZAdo1WK2NTKx+nCkCNnlSaZb9UXVBdo5oAFySA9mQXw/OAhPGflcas0/p 4lUl/0WEgGe/cfs2a1R/8QGvEg1wLv7d1T6RuT2JqhpVS9uDnl3PnjAhNORh+aeD rYPbXxwEW8gsuqk8wx1l3ejXY++woRy2KsJbIDI19vCquSdkcpwjJ0fCAk9bs0Xr S42OC7JUtT9R+g3qiGvdPt17xwN7Tgkqez+Ki+vBZJjmGUgAnxOdKxHzCHCIyPMQ LaDzp0NZBFGIpvN3aXzcPl+TmHFKIeSP+0E22JzxyyTxbWVI2sV85g== =aDax -END PGP SIGNATURE-
Re: Generating new IDs for cloning
>than you think, either bind-mount tons of filesystem from the host, >and this is only safe-ish if both run sysvinit Like most of the time, your allegation is lacking any facts and sources. Why should that not work on systemd? -nik
Re: Generating new IDs for cloning
>Longer answer: it’s complicated, but I’m sure there’s >a set of bind and non-bind mounts that will work for >systemd as well. > >Back to topic now. Or I’m going pet the cat. Well, it *is* on topic. I have been using the same strategy for sysvinit and systemd systems for many years with great success, and I would like to know what I did wrong. -nik
Bug#1035108: ITP: rdflib-sqlalchemy -- RDFLib store using SQLAlchemy dbapi as back-end
Package: wnpp Severity: wishlist Owner: Dominik George X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rdflib-sqlalchemy Version : 0.5.4 Upstream Contact: Mark Watts * URL : https://github.com/RDFLib/rdflib-sqlalchemy * License : BSD-3-clause Programming Lang: Python Description : RDFLib store using SQLAlchemy dbapi as back-end RDFlib-SQLAlchemy is a formula-aware store for RDFlib that uses SQLAlchemy to persist triples in relational databases. I will maintain the package under the Debian Python Team. -BEGIN PGP SIGNATURE- iMAEARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCZE15njEaaHR0cHM6Ly93 d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3UpmAP4nttkSjVJbdmIU0ECtjWju Z00zP7ebS3KHBCGyww0XLgEA+lIczQMdcGq7n9TOKRryhAhQ8hRwdWj7uc8cCQ5R jQ8= =tzxJ -END PGP SIGNATURE-
Re: Questionable Package Present in Debian: fortune-mod
> So, let's at least be consistent. Totally agree with that. Debian is not a collection of harmful content, it is an operating system. But, unfortunately, there are too many people in the project who think, in the name of "free speech", protecting racists, nazists, and anarchists is more important than protecting PoC, jews, or other minorities. -nik
Re: Questionable Package Present in Debian: fortune-mod
>The mission you have chosen for yourself, then, is to identify all those >things in the Debian distribution that are not constitutive of an >operating system. That is a major part of the work of a Debian Developer, and the ftp-master team. Packages are evaluated for eligibility to enter the distribution all the time, we had times where every new binary package was frowned upon due to resource constraints on the archive. If I uploaded fortunes-natureshadow because I think my favourite quotes are worth being shipped with an operating system, I am pretty sure it would get rejected. There is no reason to handle fortunes-off any different. -nik
Re: Questionable Package Present in Debian: fortune-mod
Hi Marvin, >This is simply and blatantly incorrect. Debian is a distribution. To some, that is the same. If you think describing Debian as an "operating system", then for a start, you should go and propoae to update the banner on the front page of https://debian.org/ -nik
[RFC] Extending project standards to services linked through Vcs-*
Heisann, [ for reference, the general discussion was held in 2019 already, in a slightly ] [ too big context [3]. ] as many of you will know, I am heavily involved in tearing down obstacles in the way of contributing to free and open source software (with a focus on very young people). As a Debian Developer, I am proud to use and contribute to a distribution that is among the top projects in that regard, by… * …depending almost purely on its own infrastructure * …not caring the least about any personal attributes of contributors * …having policies in place that are (legally) acceptable by virtually everyone, only limited by legislation, if at all * …putting great freedom in the choice of tools into the hands of contributors * …actively fostering education and young people However, there is one aspect I sometimes find to cause a break in this outstanding pattern: The ever so often discussed maintenance of source packages in (Git) repositories (for the sake of simplicity, I am ignoring non-Git VCSs here). Basically, as a quick summarization, the rules for VCS usage are: * Maintainers are free to use a VCS for packaging, or not * Maintainers are free to choose any VCS they like * VCSes can optionally be linked to source packages through the VCS-* fields [1] * Policy somewhat requires VCSes that are linked in VC-* fields in source packages to be pblicly accessible * Maintainers must use the official contribution channels (i.e. the BTS) even if they use a VCS [2] In essence, we could, somewhat polemically, conclude that: Packages may be developed in a VCS repository for the maintainers' delight, but these repositories are not an official part of the package lifecycle from a distribution perspective Generally, not having a clear policy on that VCS package maintenance means is, in my opinion, one of the major obstacles when trying to contribute to Debian. Part of this is the freedom maintainers have in using these tools. This results in variosu different approaches, two of the rather problematic ones including using a VCS, and then frowning upon contributions outside the VCS, and using a VCS, but then not allowing contributors to use the VCS as well. In contrast to the huge discussion in 2019, I would like to propose a softer set of policies to tackle this problem, with the ultimate goal of allowing collaboration for everyone indeendent of whether a VCS is used or not. Besides the social challenges that come with maintainer decisions, the measurable aspect is whether contributors can collaborate on the VCS or not, if they want to and if the maintainer generally accepts contributions there. For the current picture, here is a summary of where VCS repositories linked to source packages are currently hosted: Debian infrastructure 181969 GitHub.com3898 GitLab.com 334 A full ranking of the VCS hosts can be acquired using UDD with a query like select substring(vcs_url from '(?<=://)[^/]+(?=/)') as domain, count(vcs_url) as count from sources group by domain order by count desc; The issues with GitHub as an example were discussed from a freedom perspective in 2019 in a sub-thread [4] – the essence being "GitHub is non-free, noone should hae to use non-free services to contribute to Debian". Instead, I'd rather like to examine the situation from an equlity perspective, and from a perspective of extending the general tenor of DFSG (in particular, point 5) [5] to other terms besides licenses. For instance, that would be: "The terms of use must not discriminate against any person or group of persons." The essential doctrine would be that we, as the Debian community, must not impose any limitations on who can contribute, in addition to those potentially imposed by governing laws, and that we must ensure that all people that can participate at all can do so under the same preconditions. For the GitHub case, the problematic terms would be that in order to register for a GitHub account, users must be at least 13 or 16 years old (depending on the jurisdiction) ant must not live in a country under US embargoes. Now, some will argue that it's still optional to use the VCS, and that anybody who wants to contribute to a package can unconditionally do so using the BTS, even if the maintainers use a VCS repository. That would, of course, require a stric policy placing all maintainers under the obligation to accept contributions through the BTS, even if they use a VCS. But, I want to go one step further and think about who is invited to do what. If *some* people are invited to contribute through the VCS, and others are not, this does not fulfill the requirement of equality. So, if we invite one person to contribute through a VCS platform, we should invite everyone to do so. Now for the concrete implementation of this idea: I propose to a
Re: [RFC] Extending project standards to services linked through Vcs-*
Hi, On Mon, Aug 21, 2023 at 09:48:26AM -0700, Russ Allbery wrote: > Dominik George writes: > > > For the GitHub case, the problematic terms would be that in order to > > register for a GitHub account, users must be at least 13 or 16 years old > > (depending on the jurisdiction) ant must not live in a country under US > > embargoes. > > This implies that Salsa is happy to create accounts for people under the > age of 13, since the implicit statement here is that Debian's own Git > hosting infrastructure is less excluding than GitHub. > > That's a somewhat surprising statement to me, given the complicated legal > issues involved in taking personal data from someone that young, so I want > to double-check: is that in fact the case? That is, in fact, the case. And no, it's not not legally complicated to collect personal data from children. If we, for now, only look at COPPA and GDPR, the laws relevant for the US and EU, respectively, the situation is: * You can accept consent from children, if: * it can be, objectively, assumed that they can overlook the consequences of the data collection → we can assume that, if someone sucessfully contributes to a Debian package, they are knowledgable enough, given that Salsa only collects a pseudonym and an e-mail address * you don't use the data for marketing or profiling purposes → we don't do that * you don't direct commercial advertisements at children → we don't do that * you don't explicitly advertise your service to children (as in, promising them a benifit exceptionally attractive for children) → we don't do that Even if we did one of the above things, we'd still be able to accept children if they have parental consent, which is a bit tricky (but, should we get to this at some point, be outsourced to a trusted partner, like Teckids, who has expertise in that field). If we get to this point, I will certainly fight to accept children with parental consent, even if it implies some work. GitHub and a lot of other services, however, in addition to not being able to allow children without parental consent, also don't accept them *with* parental consent. As it stands, Salsa (and a lot of other Debian services) are not GDPR-compliant because they do not have a privacy statement making the above clear, but while related, let's not mix that into this thread. Cheers, Nik signature.asc Description: PGP signature
Re: [RFC] Extending project standards to services linked through Vcs-*
Hi, > have you considered dgit? no, as that's something entirely different. dgit does not manage source packages in Git, it provides a Git frontend to source packages not managed in Git. -nik signature.asc Description: PGP signature
Re: [RFC] Extending project standards to services linked through Vcs-*
Hi, > As an aside, unless something has changed very recently, GH does not > give you a way to disable PRs (issues yes but not PRs). > > If that has suddenly become possible, I have around a thousand > projects I help maintain upstream on a non-GitHub (open source) code > forge and would love to have a way to disable PRs on all the GH > mirrors of those. For now we run a periodic bot that scans for open > pull requests and closes them with a comment telling people where to > find our contributor workflow documentation. Thanks for the hint! You are indeed right – disabling pull requests is not possible on GH. In any case, making it prominently clear that pull requests are not the primary way of contribution, would be sufficient for the case in point. -nik signature.asc Description: PGP signature
Re: Hosting the original youtube-dl sources on salsa?
Hi, On Thu, Oct 29, 2020 at 04:59:53PM -0300, Rogério Brito wrote: > Since the tree was taken down (and, to boot, of the 18 forks listed in the > takedown request, mine was explicitly listed), I fear that me uploading the > lastest tree to GitHub is asking for trouble. > > Given this situation, can I upload a backup of youtube-dl to salsa under my > user account? I already maintain the packaging of youtube-dl in a different > repository that is both on GitHub and on salsa. Should I take it down from > salsa? >From an individual point of view, I strongly support you uploading the tree to as many places as you feel like, and I consider it the Debian project's duty to defend that. The RIAA seems to be targeting the most vulnerable and leat likely to defend themselves, otherweise they would be targeting those who upload content violating copyright laws instead on free software maintainers. (Also, there is YouTube Premium which allows for downloading any video ypu like, so in the view of the RIAA, why is that acceptable?). IANAL but as a project member I strongly encourage you and the project defending your right to produce free software alternatives, given that commercial software doing the same thing seems to be ok! -nik
