Re: removal of svenl from the project
Coin, I don't know Sven enought for a comment, but this is the first time i hear about problems with him. Andres Salomon <[EMAIL PROTECTED]> writes: > Step #2 requires the support of some 15 developers. This meaning 15 is a representative set of 972 persons (1.5%) not randomly choosen, which is obvioulsy wrong, and ridiculously small. What is wrong here, is not even this demand for removal with such a lack of clear evidence (you can wait for supporters, but you should also convince other people, not so much in touch with Sven, you are right), but a complete failure of this procedure. Such a lightweight proposal should never have passed the DAM filter in step 1. Moreover, having only 1*Q persons needed to open such a GRAVE process is so incredible !!! -- Marc Dequènes (Duck) pgpr9sGDR1jmC.pgp Description: PGP signature
Re: [Build-common-hackers] Re: my CDBS gallery: real-world rules samples
Coin, Caio Begotti <[EMAIL PROTECTED]> writes: > On 12/09/2006, at 14:00, Arnaud Fontaine wrote: > Hmm maybe I didn't get it, Arnaud. What you meant? > Also, if you has found some blank file in the gallery... please let me know. Fact is people learning CDBS won't make a great example. So i'd rather suggest to gather some examples of good quality, with links in the documentation, or even parts of the rules pasted in it, to have a real compendium on how to solve common (or less common) problems. How these examples could be approved, is hard to define. Having snapshots of configurations would help ensure quality, and could be commented inside the documentation, so managed by the documentation maintainers for example. > PS: Duck isn't subscribed to these lists anymore? Just checking to avoid > harassing him with tons of mails I'm still on the list, but quiet, as i'm lacking time to be more involded, nevertheless :-(. -- Marc Dequènes (Duck) pgptdigvgltqC.pgp Description: PGP signature
Re: CDBS and dh_install
Coin, Christian Perrier <[EMAIL PROTECTED]> writes: > I tend to agree. I tend to agree too, every maintainer should be encouraged to understand the packaging tools he is using. These tools are made to solve _common_ situations, so you have to understand what automatic mechanisms are involved, and sometimes their behavior must be changed or a specific rule written, so you need enought knowledge to write rules yourself properly. > I think it's important for new maintainers to understand how their > packages are built. For this, the very classical approach of > debian/rules with debhelper commands is a good compromise between > readability and accessibility. This is a good exercice, as packaging a medium difficulty package without debhelper is a good NM excercice. > On the other hand, the constant changes and new neat features > introduced in Debian (new debhelper commands, new ways to handle > stuff, etc) is a big challenge for maintainers to cope with (in short, > I bet that mostly noone except the debhelper maintainer is really > aware of all debhelper nice features). Yep, and you can't ask a NM to deeply understand the insides of each tools. But it must be aware of what it realy does. So i do agree to your statement that the CDBS documentation has room for improvement. > Using cdbs is indeed a very convenient way to be sure that packages > use a kind of common build method, which allows major build design > changes without big communication to developers. Of course, this > assumes that cdbs is kept up-to-date with recent evolutions of the > Debian packages build process and new neat features in debhelper. It was not up-to-date for a long time, since Jeff Bailey moved to Ubuntu has clearly has no remaining time for any Debian work. Peter Eisentraut came hijacking the package and did a quite good job, so the package is in a better state now. But this raise another related subject: such an important package should be comaintained. Peter refused any cooperation, uploaded new versions while i proposed to review his changes with another developper, and finally any big mistake occured (#365085 fixed by NMU). The CDBS Team does no more exist and Peter is the only one working on it and refusing any help, that's a very bad situation. For the documentation issue, CDBS only contained one or two files with obsolete and not-understandable examples, which are now removed from the package. When i came to CDBS i was moaning loudly about missing documentation (GNOME Team people are witnesses), so i finaly decided to write one. Jeff accepted me as being officially in charge of the documentation, so i introduced it in July 2005. Peter decided to rework it without any notice and then forked it because he refused to work with me. He changed the tone of parts of the document, did some cosmetic changes, but still his latest changes to the software remains undocumented. I'm still maintaining the original documentation (which is outside the alioth project because i never had any svn access, Jeff was too busy). I also started translating in french (someone provided an unfinished Brezilian translation a long while ago, but was later unresponsive, so it is quite outdated now) using po4a. So, i'm still willing to work on this documentation, but since Peter does not want to deal with me, i'm stuck ; this has to be solved before any major rewrite. Now that people are *really* interested in having a better documentation, i would be happy to get help from bubule or anyone with knowledge on CDBS and translations. The original documentation can be found here: http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml (sources are in the 'cdbs-doc/' directory) -- Marc Dequènes (Duck) pgpXyuODfIshx.pgp Description: PGP signature
Re: CDBS and dh_install
Christian Perrier <[EMAIL PROTECTED]> writes: > Hmmm, that sounds weird to my ears as Peter is currently working with > myself, Steve Langasek and Noèl Köthe on the samba packages...and this > team work works pretty well. Sounds very strange to me. I reviewed his first upload, found a regression (not in the feature because it was new, but in the global CDBS expected behavior), he refused to admit it was important, and then did everything on his own. He finaly accepted to give public access to the repository recently after several people complained on the list. And moreover, he decided to anihilate the documention changelog, which issue had to be moved to -policy before he accepted to resurect it. Some of these issues have public writings on the list. > There has even been some situations where some of us (ok, mostly Steve > who is very good at argumenting things when he disagrees) disagreed > with Peter's choices and Peter happily reverted them. He is acting as a lonesome cowboy with CDBS. And i think this now important package (as it is now widely used), MUST be comaintained. Other people in the team are not responsible since more than a year, so he is really alone. > So, I suspect some misunderstanding somewhere and I'm having hard > times buying the fast that Peter Eisentraut is completely refusing > team work. I'd suggest trying again, indeed. No, i won't try anymore by myself, it is useless, he does not care. But if your could ask him to express his problem with me or with comaintainance clearly, i'd be happy to know where is the blocking point. As you are getting on well with him, i'd be glad if you could help. Until this is solved, i'm still maintaining my original version, since more people use it than the one in the package, but this is not an ideal situation. -- Marc Dequènes (Duck) pgppLqfQbzMvs.pgp Description: PGP signature
Re: CDBS and dh_install
Joey Hess <[EMAIL PROTECTED]> writes: > To be fair, debhelper is not co-maintained either. I never noticed it wasn't, but i do think it should. Fact is you're taking far much care when integrating changes, that's a major difference. -- Marc Dequènes (Duck) pgpmw2zfDouEZ.pgp Description: PGP signature
Re: CDBS and dh_install
Coin, Steve Langasek <[EMAIL PROTECTED]> writes: > and replace it with a very small shell script. For cdbs, you delete one > line and have to replace it with your reimplementation of a very large > makefile... That's obvious because CDBS does not target at doing little independent tasks (even if some may be *perhaps* be transformed to dh_*), but to autogenerate rules. CDBS is a layer over debhelper, this cannot be simply compared this way. > Oh, I disagree; I think I have a pretty good idea what the benefits are of > CDBS, I just think that many CDBS proponents underemphasize the *downside* > of CDBS. That's not true for everybody. The auto control generation is now never run automatically because we agreed it could cause harm. > So tell me, how do you know a priori whether the software you're packaging > is going to be "common", or if it's going to need to deviate from CDBS at > some point in the future? If you're recommending a packaging style to a new > packager who probably doesn't have the level of committment to learn more > than a single helper style, how do you know whether they will at some point > need to package something that doesn't fit in cdbs's neat little view of the > world? You simply don't care about this... If something is missing or inadéquate you juste hook on makefile rules and add your own commands (debhelper if necessary). you can even stop including some classes and reimplement what is uncommon and thus has no reason to be in a class. I never found any package being fully uncommon, so i see no reason not to use CDBS if you feel well with this tool with any package.. If the packager has no time to learn Debian tools correctly, then he must not be sent to NM, or must not be accepted by AM or DAM, that's really obvious. People willing to have a @debian.org email for fun or unwilling to learn and work seriously can just can become MOTUs... What would you say if i told you i had not yet time to learn how the BTS work because my level of committment is not high enough and that i won't be able to manage my bugs until 6 more months ? Sometimes i really don't understand you... > I was pointing out that you can't learn anything about what cdbs does by > looking at the debian/rules of a package that uses it. If I have a > debian/rules file that invokes a command, and I don't understand what that > command does, I can look at the manpage. If I have a debian/rules file that > includes other makefiles, my choices are to look at the include file itself > and study it (for which the *shortest* of these is as long as the stock > dh-make template rules file), or track down the cdbs documentation... which > in at least one noteworthy case tells me to go look at the include files > anyway (hee). This was true and is less and less true. This case is in an unfinished part (debhelper parameters), and i don't recall any other case. I'm not sure in the youth of debhelper manpages were initially perfectly exhaustive. This is very common in FOSS projects to have lacks of documentation, CDBS is no exception. The documentation is still work in progress and is actively improved over time, just be patient *or* help. > The flip side of this is that the behavior of cdbs-using packages is always > changing, without the knowledge or control of the package maintainer. E.g., > while I was drafting this message, > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372273;msg=10> showed up > in my mailbox... In the past some mistakes were done in debhelper too, even if i don't recall a specific case to mention. That's not often this happen to CDBS, but i agree this should be avoided, that's why i'd like Peter to finaly accept co-maintainership. > No, clearly makefile includes shouldn't have manpages; but some kind of > documentation that tells cdbs users what they should or shouldn't be able to > depend on would be a good idea. In the absence of such documentation I > think the current answer to what they can depend on is actually "very > little", which is a big part of why I don't encourage its use. A documentation do exist, even if you seem to be completely blind and features which are described are behaviors you can count on. When a feature has changed for very important reasons like the control auto generation one, a warning is displayed (so you know you cannot count on it). Undocumented parts are either documentation lack or internal stuff you should not care about and count on. Nevertheless, i do agree this needs improvements (please reply to the part of the thread with bubule if you want to continue on this specific topic). -- Marc Dequènes (Duck) pgpGN7Uu1aDZd.pgp Description: PGP signature
Re: CDBS and dh_install
Mike Hommey <[EMAIL PROTECTED]> writes: > Probably because a change in debhelper is done with a change of > compatibility level. And you still can use the old behaviour by using > the appropriate level. I was talking about mistakes, and package care, and package reviewed by several persons of a team so as to avoid this situation, and you're talking about planned major feature changes. You're out of topic. -- Marc Dequènes (Duck) pgpPDJSYpppnV.pgp Description: PGP signature
Re: CDBS and dh_install
Mike Hommey <[EMAIL PROTECTED]> writes: > Probably because a change in debhelper is done with a change of > compatibility level. And you still can use the old behaviour by using > the appropriate level. I was talking about mistakes, and package care, and package reviewed by several persons of a team so as to avoid this situation, and you're talking about planned major feature changes. You're out of topic. -- Marc Dequènes (Duck) pgp1nwqwLKqBL.pgp Description: PGP signature
Re: Move to python 2.4 / Changing the packaging style for python packages
Coin, Ben Burton <[EMAIL PROTECTED]> writes: > For reference, decompyle still needs python2.3. There are two issues: > > 1. It won't build under python2.4. I have fixes for this that I haven't >uploaded (and that need some more testing and tidying up). You may still ask for help. > 2. It won't decompile python2.4 bytecode. This will be somewhat harder >to fix (and I haven't done it yet). If it is not able to decompile recent python version, then it is a kind of useless one. Python 2.4 is out since a while, what are upstream plans for their software ? -- Marc Dequènes (Duck) pgpsjzv7w4QG9.pgp Description: PGP signature
test
Re: Bug#219277: ITP: gnusound -- Powerful sound editor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Coin, Gnusound is using OSS only. Yet, afaik there's no plan to add Alsa/Esd/Arts/... support. The included TODO file reads that the upstream author is likely to fix many technical and cosmetic bug before adding big features. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/q3MIsczZcpAmcIYRAiXHAJ0bw42qtykTvTHODAkiKJrtOwhXxwCfeFm/ 6bhuUya/xkFLG3MKQcZzjT8= =OgIr -END PGP SIGNATURE-
Re: Bug#219277: ITP: gnusound -- Powerful sound editor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Coin, You'r right, "Powerful" is not adequate, i just took author's descriptionw without taking care of it. I asked the author if it was possible to use it without gnome support and he said it was not, so i suggest this : s/Powerful /gnome / Proposed Description : GNUsound is a gnome sound editor. It supports multiple tracks, multichannel output, and 8, 16, or 24/32 bit samples. It can read a number of audio formats, modify them, and saves them as WAV files. GNUsound supports a large number of high-quality audio effects, filters, and converters through the LADSPA plugin architecture (band pass filter, frequency shifter, reverb, flanger, pitch scaler, pink noise, stereo to mono converter, and many others). Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/q3ydsczZcpAmcIYRAnUAAJ4+6bImG5bE/DtOb10iMq2Igcck6ACfc4Z2 QMc3LQ0XNdLDyOWcvnCDmpI= =bEOJ -END PGP SIGNATURE-
Re: ITP: ircd-ptlink -- IRC Server from PTlink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This ITP was badly written as it was my first attempt, sorry. Here is a better one with an improved Description : * Package name: ircd-ptlink Version : 2.23.6 Upstream Author : PTlink Coders team <[EMAIL PROTECTED]> * URL or Web page : http://www.ptlink.net/ * License : GPL Description : PTlink IRC server ircd-ptlink provides an advanced IRC server, fast and reliable, with support for SSL client connections, ziplinks, halfops, advanced channel modes (anti-spam, no nickchange, flood control, ...), sxlines, and some other nice features.
Re: ITP: ircd-ptlink -- IRC Server from PTlink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Coin, This ITP was badly written as it was my first attempt, sorry. Here is a better one with an improved Description : * Package name: ircd-ptlink Version : 6.16.1 Upstream Author : PTlink Coders team <[EMAIL PROTECTED]> * URL or Web page : http://www.ptlink.net/ * License : GPL Description : PTlink IRC server ircd-ptlink provides an advanced IRC server, fast and reliable, with support for SSL client connections, ziplinks, halfops, advanced channel modes (anti-spam, no nickchange, flood control, ...), sx-lines, and some other nice features.
Re: Bug#219293: ITP: songwrite -- a tablatures editor and player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Proposed Desciption : Songwrite is a guitar tablature (fingering notation) editor and player, quite similar to TablEdit. In addition to tablatures, it also supports staff, lyrics and drums. Printing and playing support are available through external programs. Songwrite was formely know as GTablature. Duck and Jiba -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/rOR4sczZcpAmcIYRAlNzAJ4gpU9hMyqRwM8iqJwAdCPpxQbklACcCjoP MOSl+i4ZiiDIySq8dwdgAN0= =pQHQ -END PGP SIGNATURE-
Re: Bug#219251: ITP: ircservices-ptlink -- IRC Services for PTlink IRCd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Proposed Description: ircservices-ptlink provides powerful IRC services (NickServ, ChanServ, MemoServ, NewsServ and OperServ) for the PTlink IRC server. Vlinks, securemode, guestnicks and logonnews are supported. The last sentence in the old description was crap. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/rOkbsczZcpAmcIYRAty2AKCnHL+Jakkr2cKFOWzgyX2nlxPcfgCeJH4r pCOU9jucUnhl8QbuNY6SfRw= =HnpW -END PGP SIGNATURE-
Re: Bug#219276: ITP: ircopm-ptlink -- Open Proxy Monitor for PTlink IRCd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Proposed Description : ircopm-ptlink provides a security service for the PTlink IRC server. This service is able to scan clients on connect for open proxies, and add G-lines on them for security purpose if needed. Could you have a look at my first bad writtent ITP, please ? (Bug #219200) Thx for help. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/rOsPsczZcpAmcIYRAtXkAJ41qHFoE86nOvrKGj1nSsS+6kSFaACeMnon akpp++saSWor3ja2jC6JTsI= =jnTz -END PGP SIGNATURE-
Re: Bug#219277: ITP: gnusound -- Powerful sound editor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You'r right, i checked and saw it is not part of the GNU project. I contacted the upstream author and explained him the problem. He should sort out his situation in a near future. I suggested him to mail [EMAIL PROTECTED] and ask about entering the project, so did he. to be continued... Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/ramGsczZcpAmcIYRArwxAKCIQGQE2bMWNNtnIQXF7xV8oFzjEACeKNoG q0nn+jdBuUFtM7AZVU3FoPw= =gvZf -END PGP SIGNATURE-
Re: Bug#219281: ITP: pyopenal -- port for Python of the OpenAL library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Please rename the package to python-openal and probably pythonX.X-openal > whereas X.X is the Python version built against. The package source name is not at all misleading or conflicting, so i see no real reason to change. Nevertheless, i forgot the dummy packages depending on the right python version, thx for telling me. A new release correcting this on editobj, py2play, pyopenal, soya, and genetic will be uploaded soon. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/rxjXsczZcpAmcIYRAuX4AJ9tkJ7yaHP8Vn52HVJ31grpjqDWiACfQYVB taE3qWPmo2LXRr/OetLBcBg= =rXzz -END PGP SIGNATURE-
Re: Bug#219293: ITP: songwrite -- a tablatures editor and player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Winston <[EMAIL PROTECTED]> writes: > On Sat, 2003-11-08 at 15:18, Joe Drew wrote: >> On Sat, 2003-11-08 at 07:41, Duck wrote: >> > Songwrite is a guitar tablature (fingering notation) editor and player, >> > quite similar to TablEdit. >> > In addition to tablatures, it also supports staff, lyrics and drums. >> > Printing and playing support are available through external programs. >> > Songwrite was formely know as GTablature. >> >> Good description. >> Here's how I'd format it into paragraphs: >> >> Songwrite is a guitar tablature (fingering notation) editor and player, > > Perhaps "string and fret notation" instead of "fingering notation"? > Google seems to disagree, so i'd rather not change. >> quite similar to TablEdit. In addition to tablatures, it also supports >> staff, lyrics and drums. >> . >> Printing and playing support are available through external programs. > yep > I'd say, "Printing support and playback are available via external > programs." > >> Songwrite was formely know as GTablature. > > "Songwrite was formerly known as GTablature," is better. right Thx for your help. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/rxXNsczZcpAmcIYRAmRpAKCSFOhuhkG91f5AUxZtm/1u0c3qmwCgocZx OGZySVKFEkqmo9wOdV/WabA= =QxZc -END PGP SIGNATURE-
Example of really nasty DD behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip Van Raemdonck <[EMAIL PROTECTED]> wrote : > libxklavier & gswitchit packages are uploaded and waiting to be added by > ftp-master. This nasty behavior shows that being an officiel Debian developer does not mean quality. I was writing an ITP when you posted that and suddendly, saw all my work preparation turned into ashes. You did work on your own without any notice. May i remeber you the use of IPTs and RFPs ? These are tools to inform people about works to be done and work in progress in order to avoid duplicate work. As u did not fill any ITP nor informed anybody on this RFP, u did make me loose my time preparing for doing this packaging. Moreover, while you were running to be the first guy to upload a package, you forgot that working hand in hand with the upstream author is the best way to produce a work of good quality. I did contact him, but you didn't. Another thing, someone had already packaged this program (see web site); he is not a Debian developer and has not enought time to become one. But he has done an interresting job and you could have contacted him and ask him gently if he was interrested in entering the maintainer process (because he could have made this package to be prepared and then propose it into Debian). You could have some respect for his work, even if he is not a DD. I did contact him, but you didn't. I'm informing these two persons about the situation, because i'm sure u do not have a second for such social activities. Thx for remebering you're not alone in the world... Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/tq7ssczZcpAmcIYRAnS5AJ4xugTDwfVLBocOlpo2GMYVeNTD3gCcCpnm 1owYx8FBA+E4TaTwjL+Q6Hs= =HeXx -END PGP SIGNATURE-
Already done by someone else
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Coin, Somenone already did the job and forgot the BTS usage. (see #163252 for more details) So, i'm closing those ITPs. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/tq/hsczZcpAmcIYRAqRdAJ9GnwhUh0RLlbZRsOgkpyImn2tKLwCfSDu2 9iocODQQjBiqJZNRuMxWbI4= =EusX -END PGP SIGNATURE-
Re: Example of really nasty DD behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chad Walstrom <[EMAIL PROTECTED]> writes: > Duck, perhaps you should have written the ITP earlier. Instead of > complaining, why don't you thank your fellow developer and offer to > co-maintain the package. Perhaps the package could benefit from your > combined efforts. > As Martin Pitt said, I think it's wise contacting related persons, look at the program, and then, when you relly want to package it, write an ITP. I won't post hundreds of ITPs in advance to be sure to get the packages i like and then reopen them when i don't those. I said i contacted people, looked à the program, but i didn't package anything. My ITP so came just before any real packaging work, and i don't think doing it earlier would have been adequate. I don't think this "fellow developer" wants to share HIS package with anybody. And i don't think i'd like to work with a guy who is unable to communicate. I was just complaining about his behavior, i don't mind having this package or not. I've got enought packages to deal with, i just wanted to help the gnome packaging team (Sebastien Bacher is actually my sponsor) because this nice program was missing. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/t3hCsczZcpAmcIYRAtGaAJ9fc/EZuub23Df4/gVAw579nRt3XwCeJXi/ ngTtikWG7tFbuyHXj4020zA= =ngvk -END PGP SIGNATURE-
Re: Example of really nasty DD behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamish Moffatt <[EMAIL PROTECTED]> writes: >> I was writing an ITP when you posted that and suddendly, saw all my >> work preparation turned into ashes. > > "Duck", why did you do any preparation before writing the ITP yourself? > >> You did work on your own without any notice. > > So did you it seems. NO, you're wrong, look at my reply to Chad Walstrom. > >> I did contact him, but you didn't. > [...] >> I did contact him, but you didn't. > [...] > > ... but none of this is essential. > I fully disagree. A good cooperation with upstream is really important to relay bugs, improve the software (build sys, compliance to the FHS, ...), ... When the program is GPL then u don't need upstream permission to package it but i find it more respectful to contact the author. Or that would be like not saying thanks because something is gratis. > On the flip side, he's a Debian developer and you would have had to find > a sponsor etc. I would rather have a package from a registered > maintainer, if you don't mind. > Please check what you assert. I already have a sponsor, some packages in the archive, and registered to the NMP. (http://qa.debian.org/[EMAIL PROTECTED]) (http://nm.debian.org/nmlist.php) Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/t35+sczZcpAmcIYRAv+GAKCBjjuPSZ7LdTKCN9UBmgzjYT5VhACdFwG8 jMu4XyRvTqNOEcmyt7hgB/A= =hT6f -END PGP SIGNATURE-
Re: Example of really nasty DD behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josip Rodin <[EMAIL PROTECTED]> writes: > ITP means simply "intent to package". Anyone can, and judging by this case > probably should, announce their intention as soon as they see the program or > the RFP. You can always either confirm or withdraw your ITP later. Good behavior that to treat ITPs in an offhand manner. > I'm sorry that you feel disappointed, but the other developer didn't seem to > do anything "really nasty", he was merely much more expeditious than you > were. He could have posted his ITP sooner, too (unless in the unlikely event > he actually made the package in a few minutes), but it's not such a big deal. Being "expeditious", make "package in a few minutes", lack of communication are some reasons why Sarge is still not out. Bravo ! I really wonder why the NMP exist, once DD you can do things without being serious any more, and many agree. Filip is probably a good packager, but i still disagree on that way to do. I told my opinion and this conversation is over. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/t6MBsczZcpAmcIYRAkahAJ9BUKtgNh1UBEt/5/Sf8idveHW9lACbBpq2 LTTXb1oF5l//G7rKJUxQYgY= =fZjk -END PGP SIGNATURE-
Re: Example of really nasty DD behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Filip Van Raemdonck <[EMAIL PROTECTED]> writes: > May I remember you it's retitling an RFP into ITP you responded to? > Which was meant to avoid anyone else going through useless effort while > the packages are waiting for ftp-master intervenience. When i started composing my ITP it was not retitled and you had not yet replied. I was interrupted many times so it took me 15-20 to finish it. I am not lying. > Uh-huh. So where was yours to avoid others' duplicate work? My ITP came on time, before any packaging. > I think it's wise to see if one is capable of building packages, then ITP. > As you state, there are too many ITPs which are never fullfilled. > Since in this case it was an old RFP, I immediately uploaded the packages > as well. Yes, too many people not really serious. Your quick upload without any upstream/old-packager contact made me think your were not. > Pity. One of these weeks I was about to contact you to see if you were in > need of a sponsor of arkhart, following up to > <[EMAIL PROTECTED]> > Which is a message you sent to debian-mentors 3 months ago, while you only > sent ITPs for arkhart 10 days ago. Seems you are a little late yourself? I thought findind a aponsor was first required, i was wrong. As you said i looked for a sponsor for many months, and i had no reply, so i found unnecessary to "reserve" packages in advance. When i got a sponsor, i did correct this quickly. Arkhart is uploaded and waiting for approval, so u'd be able to have fun with it soon :-). In the meantime, you can try slune. > *Shrug* > Well, the offer stands. I'm currently working out things with someone else > to sponsor an RFAd package, but when that's worked out I'll sponsor you, > if you wish. I've already found a sponsor. Thx for your proposal. Please understand this was not a personnal attack. There's so many people doing nasty things (like a so famous video player packager) that i found really important to give a word on the situation. When you find several ITPs filled more than 6 years ago and an official DD "seems" not to mind about using the BTS properly, you may wonder about the future of your prefered distribution. Thx for your explanation and proposal. Duck -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/uKO0sczZcpAmcIYRAh51AJ48j3ntUkLFryxNE5vaea3Qu/W/0gCfZOMU +1ALNbQVJxOe0QbFOfi2624= =03lK -END PGP SIGNATURE-
Re: Example of really nasty DD behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamish Moffatt <[EMAIL PROTECTED]> writes: > I think you are placing too much emphasis on the ITP and the WNPP > system. I think it has a useful place in avoiding (some) duplicate work, > searching for new owners for packagers etc, but don't expect every > transaction to go through that system. I really think this is a good tool and i still feel that having gathered all important imformation about packages was a wise idea, even if you discuss and coordinate using a mailing-list. Looking for problems in a package takes few minutes using BTS/PTS/... , whether in mailing-lists it can take hours or days. > Similarly I just gave away a couple of my packages to someone else. No O > or RFA bugs needed. I suppose if there were other people keen for those > packages they missed out :-| but they'd never contacted me. In this case, the package still continues to be maintained, so there is no problem, so no bug to fill in. Giving an equal chance to possible new maintainers is another suject, out of scope. > Sometimes it is necessary to work with upstream on the build system, > bugs etc. Sometimes everything just works though and you can build the > whole package without any discussion at all. There's no hard and fast > rules. Indeed it is not compulsory. I just wanted to highlight it is really important, even if not needed because packaging is trivial. Moreover, it s not only a problem a needs, bugs, build issues, ... it is, from my point of view, also a question of respect and courtesy. Sorry for being so idealist... Duck P.S. : Notice i am still signing as "Duck" and not "Marc DequÃnes", because it the way most people know me and call me in real life. Many probably do not remember my real name, so using my nickname is in fact far less anonymous. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/ujV5sczZcpAmcIYRApjTAJ0YkHZZCQK3pPcg2OJv+FFAd4NhBwCdGI9T kr7bl6cIzXxfusQt3PY9N6I= =zqjo -END PGP SIGNATURE-
Re: Cdbs Features
Quack, On 2019-05-14 11:24, Sean Whitton wrote: Switching the entire Haskell ecosystem over to use dh would be a massive amount of work, as the new dh_haskell would need a lot of testing etc. So Haskell libraries and apps would probably have to be one of the exceptions. It took months to get somethings working for Python and Ruby and in the end years to polish all the things and migrate all packages, so it's clearly going to take quite some time. I think one of the major feature of CDBS is the way stages are grouped in make rules and you can hook onto it or even override. Coupled with patsubst it makes some kind of loops you can use to iterate over groups of packages, which is very handy when you need to build for various versions of an interpreter. So unlike DH you can really add or override parts of these loops if your package requires it. But in the end all these rules are complex to read and maintain, and if they were very useful in the past they also pushed debhelper/dh into going forward with more bold features and I don't think CDBS adds much to the table nowadays. I would also point out that the maintenance of CDBS has been on Jonas Smedegaard's shoulders for years now and it has been difficult having almost no backup (which I'm partly responsible of). I think I was mostly able to convince him we should work on a retirement plan but I've had no time to do anything about it. Bugs like #885407 and others are still around while we are close to release, thus I still think this is the best course of action. On the more general topic, I believe there should be room for new tools to emerge and not-being-dh should never be a RC or even important bug. Nevertheless I think this tool has grown well and a strong recommendation would be fine. I believe as a project we could agree on major goals around deprecating tools that lost traction and proper maintenance, old versions of the tools, old patch formats and so on, and encouraging contribution around it. We could also agree on some practice to avoid like direct source patching (especially when not on a VCS). But this way you're still free to use the patching system that suits you or build your own and suggest it to the community; that's how many of our tools were built. As for using NMU I think this is a bad idea. Even if we're supposed to care after a NMU, this is no long-term maintenance and a returning busy maintainer would not really appreciate this. I believe adoption, becoming co-maintainer or creating a team would be better if you want to make drastic changes on a package and your one-off patch lingers in the BTS. \_o< -- Marc Dequènes
Bug#1010247: ITP: greetd -- minimal and flexible login manager daemon
Package: wnpp Severity: wishlist Owner: Marc Dequènes (Duck) X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: greetd Version : 0.8.0 Upstream Author : Kenny Levinsen * URL : https://git.sr.ht/~kennylevinsen/greetd * License : GPL-3 Programming Lang: Rust Description : minimal and flexible login manager daemon greetd makes no assumptions about what you want to launch. Use gtkgreet to launch sway if you want a fully graphical session, or use agreety to launch a shell if you want a drop-in replacement for agetty(8) and login(1). If you can run it from your shell in a TTY, greetd can start it. If it can be taught to speak a simple JSON-based IPC protocol, then it can be a greeter. Most login managers historically assumes X11. The most compatible one is probably GDM but unless you use GNOME you may wish to have a more lightweight solution. Lightdm worked well until recently despite not having Walyland support itself but it is now afflicted by this bug: https://github.com/swaywm/sway/issues/6655 The last release dates 2018 and there is no recent coding activity. I think greetd's architecture properly decouples authentication and the login UI and makes for a good replacement for Wayland users. I was thinking about maintaining it into the Rust team but I have not joined yet. Regards. \_o< -- Marc Dequènes
Bug#1010248: ITP: wlgreet --
Package: wnpp Severity: wishlist Owner: Marc Dequènes (Duck) X-Debbugs-Cc: debian-devel@lists.debian.org Control: block -1 with 1010247 * Package name: wlgreet Version : 0.3 Upstream Author : Kenny Levinsen * URL : https://git.sr.ht/~kennylevinsen/wlgreet * License : GPL-3 Programming Lang: Rust Description : raw wayland greeter for greetd Greeter to be run under sway or similar. Note that cage is currently not supported due to it lacking wlr-layer-shell-unstable support. This ITP is intended to be fulfilled once greetd is packaged, see #1010247. I was thinking about maintaining it into the Rust team but I have not joined yet. Regards. \_o< -- Marc Dequènes
Should the weboob package stay in Debian?
Quack, (This is a followup of the thread started on debian-private. This is not a private matter at all, and we should have discussed this openly from the start.) It has been brought to my attention that this package, its name and the name of the binaries and further content was deemed offensive. This was already raised in the past (~2012 IIRC) but the package was reintroduced and has been in the archive since then. Since this is a childish naming which was not intended at being insulting, I gave a hand to package this useful tool. I would have preferred it renamed though. This thread is about giving your opinion and discussing with upstream about it, and us DD to decide the fate of this package. I hope this would help draft proper policy criteria about what we consider not acceptable. May I dare to hope we would discuss this is a civilized manner? \_o< -- Marc Dequènes
Re: Should the weboob package stay in Debian?
Quack, It seems the project is leaving the decision about Weboob onto me, so I'll try to address it. The diversity statement tells me we should welcome others even if they are very different and with conflicting opinions but nothing beyond that. There is no policy part that I found helpful. I discarded heated reaction from the thread of discussion to isolate the most constructive remarks. We've been able to draft guidelines about what we consider not acceptable at events and called this "code of conduct". This does not need to be universal but in our community we were able to agree on some criteria and I think this is making our world better. I don't think we should write an infinite list of rules but guidelines based on non-emotional objective points to consider. There was part of the discussion about the intent of these upstream authors, but we're not mind reader and in the end the impact on people, and solving this if we can, is more important than judging people. I've also excluded any consideration about the usefulness of this software. As long as one single DD is willing to maintain a software it is fine being in according to the policy. Also being very useful does not grant any special allowance to be nasty. So I've considered these criteria: 1) is it insulting? There was an insult targeting homosexuals, but a contributor proposed a fix and upstream accepted it without discussion. It should not have been there in the first place though. As for the "boob" part, it is puerile, very bad taste, disturbing that people could be so obsessed as to name their software like this, but there's no message at all so it cannot be insulting. 2) is it stripping people of their dignity? According to Wikipedia there are four main categories of problems: - is it humiliating? « It is an emotion felt by a person whose social status, either by force or willingly, has just decreased.[1] It can be brought about through intimidation, physical or mental mistreatment or trickery, or by embarrassment » In our case there is no misrepresentation of persons or anything implied from the focus on this specific anatomic part. - is it an instrumentalization or objectification? it is clearly objectifying women as a source of sexual attraction. There is no message, so no one is trying to sell you cars or manipulate you in any way with it though. Interestingly the allegory of dignity by Cesare Ripa is quite evocative. and a huge amount of what we consider art is often emphasizing on the woman's beauty in more or less suggestive ways. Weboob is clearly not very subtle about it, but I'm pretty sure other representations also make some of us feel uncomfortable. Also this representation does not target specific persons and is not representing women as weak or submissive. - is it degrading? « These are acts that, even if done by consent, convey a message that diminishes the importance or value of all human beings. » This does no apply here as there is no depiction of act or even any message. - is it dehumanizing? « These are acts that strip a person or a group of their human characteristics. It may involve describing or treating them as animals or as a lower type of human beings. » Apart from objectification already discussed, there is no implication that woman are only good for sex or any such message. Maybe some of the Weboob authors do not think highly of woman but we're discussing the package content and not judging people's thoughts (which we cannot be sure to know anyway). So apart from objectification of women, but without instrumentalization or degrading message, I was not able to find serious consequences. As much as I would prefer things to be different (I already told upstream in the past) I don't feel I have any right or special wisdom allowing me to dictate people to act and think differently. Banning content because it displease me and make people uncomfortable while no direct harm has been found is unlikely to have a positive effect. Consequently unless harmful content I'm not aware of is discovered in this package I am not going to remove it from the archive. I would consider adding a neutral warning message in the package description though, so people can individually decide for themselves if this is acceptable from their own point of view. I'll be coming at DebConf this year. Feel free to come and discuss it with me. \_o< -- Marc Dequènes
Re: Should the weboob package stay in Debian?
Quack, On 2018-07-22 09:52, Mike Hommey wrote: but... https://git.weboob.org/weboob/devel/merge_requests/232 Thanks for pointing this out. It's not in yet and I've just asked upstream to clean this mess. \_o< -- Marc Dequènes
Re: Should the weboob package stay in Debian?
Quack,
On 2018-07-22 19:16, Rens Houben wrote:
In other news for Sun, Jul 22, 2018 at 09:39:51AM +0900, Marc Dequènes
{ A whole lot of refuge in technicalities snipped }
There was no "technicalities". I decided to explain my decision and not
base it on vague feelings or emotional outburst but on this:
https://en.wikipedia.org/wiki/Argumentation_theory
No one in this entire thread was asking that this software be removed.
As explained earlier this thread starts in debian-private and I can
assure you this was raised.
Instead, all along the suggestion has been "Rename some of the programs
because Debian is not run by a bunch of puerile twelve-year-olds who
get
their sense of humor from Beavis and Butthead"
For some it was an acceptable stopgap, for others a temporary solution,
but as upstream is unwilling to rename this would mean an endless and
painful chore. Also when do you stop renaming? Would having all
binaries, package names and descriptions, manpages, --help, and so on,
so quite a lot of horrible work to maintain over time…. enough? I'm
pretty sure there would be some to object having Python code with
readable puerile things in it.
So that's true I did not explain this: I'm already struggling to have
enough "spoons" to do useful things in Debian and other projects, so I'm
not going to consider this non-solution.
I've drawn the line and if the software happens to go beyond it and
upstream refuses to fix in a timely manner I will myself remove it from
the archive. I may also refine my criteria and reevaluate later.
\_o<
--
Marc Dequènes
Re: Should the weboob package stay in Debian?
Quack, On 2018-07-25 22:35, Jonathan Dowland wrote: I think it would be worthwhile to file a BTS bug so it can be easily tracked which versions of the package we distribute still carry this bug, so I will do that. Agreed, we should ensure all fixes are in all versions and I'd be glad to have some help. Upstream agreed to fix the referenced problem without discussing, which is encouraging. So we should check the messages further and report them to have them fixed if any other insult slipped through. I think the next best step for this particular suggestion would be for me to take it upstream, and, assuming it meets with some kind of positive response, I would also be happy to work towards implementing it. So I will raise this in upstream's Gitlab. You're welcome to try convincing them. They were clear they did not want to rename but maybe they could agree on having a variant of the binaries along with the original ones. I also like the idea of a single binary with subcommands, would be easier than remembering all the commands. But as I said unless upstream does agree on something, we're not going to maintain an alternate version. \_o< -- Marc Dequènes
Re: [users] Re: Where's lame
hi developers, this is my first message, i hope it's appropriate. there's talk going on on the users mailing list about lame and its absence from the package tree. i would like to adopt the lame mp3 encoder as a debian package and was wondering if there are any objections? is there already a maintainer? can this packet be debianized? thanks, martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] -- humpty was pushed.
lame
hi developers, this is my first message, i hope it's appropriate. there's talk going on on the users mailing list about lame and its absence from the package tree. i would like to adopt the lame mp3 encoder as a debian package and was wondering if there are any objections? is there already a maintainer? can this packet be debianized? thanks, martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] -- humpty was pushed.
Re: [users] Re: Where's lame
also sprach David Whedon (on Mon, 07 May 2001 01:10:02PM -0700): > Lame cannot be included in Debian, please see: > http://www.debian.org/devel/wnpp/unable-to-package thanks for the reply(ies). i hope i didn't inconvenience anyone with my ignorant post. i'll be better in the future, promise! martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] -- echo Prpv a\'rfg cnf har cvcr | tr Pacfghnrvp Cnpstuaeic
