Proposal for collaborative maintenance of packages
[ Sorry for the crosspost, but the subject is of interest to many people ] Hello everybody, following the last discussion at the Debian-QA meeting on Darmstadt, it appears that the proposal called "Collaborative maintenance" is of generic interest : - for Debian sponsors and Debian mentors - for QA which may use the infrastructure for orphaned packages - for Ubuntu's MOTU School I tried to describe the big lines of the project in this wiki page: http://wiki.debian.org/CollaborativeMaintenance I'm crossposting this to all people involved (even people responsible of the REVU tool used by Ubuntu) because I'm sure that we should all work together to realize this project. This infrastructure is seriously needed in Debian because: - team maintenance with SVN is more and more popular, and a good web interface above a SVN repo of Debian packages would help all those teams - an official way to follow interaction between mentors and sponsors is needed and actual mentors.debian.net/sponsors.debian.net are not enough for that - we need to facilitate the work of sponsors because we're lacking sponsors - we need to let skilled external contributors maintain packages for us (when they don't want to become DD) The very same reasoning applies even more to Ubuntu where packages do not have an official maintainer. Changes on packages have to be monitored to know if a package needs to be uploaded. Also they have the same problematic of "sponsoring" with their "MOTU school". Furthermore, if we can standardize this infrastructure between Debian/Ubuntu, it will be easier to integrate packages created by Ubuntu MOTU in Debian (I'm speaking of packages which don't exist in Debian yet). That's why I'm bringing this proposal forward now. I've recently discovered the REVU tool which addresses part of the same problematic in a different way ... and the sooner we work together, the better. :) FWIW, I have an alioth project ready to be used : http://alioth.debian.org/projects/collab-maint/ I'm waiting on your feedback and I hope that we can find a good basis on which to work together. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Freexian : des développeurs Debian au service des entreprises http://www.freexian.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
Hello Daniel, Le lundi 19 décembre 2005 à 08:24 +0100, Daniel Holbach a écrit : > > - team maintenance with SVN is more and more popular, and a good web > > interface above a SVN repo of Debian packages would help all those > > teams > > I'd be in favour or a bzr solution, not because of random > flame-war-feature-reasons, but of the central approach SVN takes. You > have to handle permissions, have to take care of a lot of people, which > is not a technical problem, but a social problem too. People do feel > locked out. For me this is a non-issue : 1/ I have heard lots of good about svk which brings the decentralized thingy upon svn 2/ SVN is *much* more popular than anything else right now (at least within Debian and that what is of interest to me right now, since I want actual Debian developer to make use of this new infrastructure). I know that because I'm an alioth admin where most SVN / arch / bzr / baz / tla / whatever repo for Debian packaging are currently created. 3/ svn-buildpackage exists and works (and I don't know of any bzr equivalent) 4/ SVN is easier to learn for most people and in particular those who have experience with CVS (this might change, I know that bzr has done big steps in the right direction) So I propose to stop here this discussion about VCS before it turns out into a flamewar. :-) > > - we need to let skilled external contributors maintain packages for us > > (when they don't want to become DD) > > Although this might be a bit early in the discussion, I want to raise > awareness of other distributions that are there already and might be > soon there. This shouldn't be a Debian<->Ubuntu solution, but have a > broader spectrum from the beginning. My spectrum is Debian<->everyone else. But I naturally thought of Ubuntu since we're so close and because it's our interest to stay close ! > I informed the Launchpad team about this discussion, since I think it Who are the members of the Launchpad team ? > might be the best to have some kind of Launchpad integration for this. > http://launchpad.net/distros already shows four distros and the bug > tracker already works nicely across distribution 'borders'. I agree that integration with Launchpad would be interesting, but as long as Launchpad stays a closed-source thing, it will be difficult for Debian to create anything relying on it. Regards, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
Le lundi 19 décembre 2005 à 09:44 +0100, Lucas Nussbaum a écrit :
> First, technical issues:
>
> * Chances are very low that you will get Ubuntu people to use svn
> instead of bzr. bzr is the "official" VCS in Ubuntu, it is written in
> Python, the "official" language in Ubuntu. Making Ubuntu people use svn
> is like asking a vi user to switch to emacs.
Again, in order to kill the discussion before it starts, I want to make
things clear :
I don't want to change how Ubuntu works. I just want to find a decent
way for Debian to let external contributors integrate their work within
Debian and in particular for Ubuntu developers. Because it's in the
interest of Ubuntu developers to merge their work within Debian.
I expect anyone familiar with VCS to be able to work with svn if needed.
Much like I'm able to learn bzr.
Actually, the Ubuntu people doing REVU didn't event think of using a VCS
because they are handling uploads of source packages in their system.
Adding a VCS layer has some advantages however : traceability of
contributions from an applicant is one for example.
> * Generating a dynamic web page means using a non-distributed
> architecture. I started working on similar stuff, but with the
> assumption that maintainers will run the scripts themselves (or with
> cron). An output for ruby-related packages is available on
> http://ox.blop.info/bazaar/rubyversionslist.html . The webpage about the
> tools is https://wiki.ubuntu.com/MOTUTools . An easier approach could be
> to provide the information in an easy way on all websites so some
> scripts could fetch the pages, parse them, and generate the useful
> reports.
Yeah, this makes sense too. I'd like to have wrappers for doing things
locally :
- download source package from the good repository (without having to
type a huge URL)
- run most checks on it (pbuilder, piuparts, lintian, ...)
- display analysis
- etc.
It's a good idea to have those tools widely available and to simply use
them on a specific server to make the data available on web pages too.
> Human issues:
> * The main problem is how to define trust relationships between DDs,
> MOTUs, would-be DD and MOTU-Hopefuls :
> * Do we want to define them globally, or on a per-team basis ?
> * What should they be ? Does Debian want to trust MOTU-hopefuls ? Does
> Ubuntu want to trust would-be DDs ?
Human issues are a non-issue. We can't define who trust who. Each person
decides who they want to trust. I expect Debian developers to not trust
anyone they don't know at all, however trust can be created when review
after review they see that the person is doing a good job, etc.
On the Debian side, we still have people or teams behind each package so
they will set the rules of which contribution they can accept. But I'm
confident that with the right tools, we can enhance our collaboration.
> I think that we shouldn't try to reach a too wide scope here. Chances
> are high it will be too complex and will just fail. Why not start by
> developping tools to help Debian & Ubuntu collaborate by exchanging
> patches, bug reports and source packages, and wait for collaborative
> maintenance ?
Sure ! It's time to go in more details... my proposal only defines the
big lines. There's still much to be defined and I'll gladly accept
concrete proposals. I'll try to draft some myself when I have some time.
> Of course, the problem space of REVU and {mentors,sponsors}.d.n is
> similar, and common tools could be developed too instead of reinventing
> the wheel.
Exactly !
But applicants should directly learn how to work in teams since that
what they will have to do later anyway ... so the use of a VCS in the
process is a good thing (in the Debian point of view at least).
However that use could be hidden behind the scenes for those who prefer
to not use such a system. I'm thinking here of REVU which handles upload
of source package directly. A script could be written to integrate the
source in the repository...
=> that's the kind of discussion that I expect: finding a way to make
everyone happy with one common system (even if that system seems a bit
overkill for one side or the other, we need to get a bit of momentum
behind it to make it maintainable in the long run).
Cheers,
--
Raphaël Hertzog -+- http://www.ouaza.com
Freexian : des développeurs Debian au service des entreprises
http://www.freexian.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
Le lundi 19 décembre 2005 à 11:04 +0100, Christoph Haas a écrit : > > This infrastructure is seriously needed in Debian because: > > - team maintenance with SVN is more and more popular, and a good web > > interface above a SVN repo of Debian packages would help all those > > teams > > If there is a fixed team working on a package they propbably already use > subversion and svn-buildpackage. Right and I've seen regular post for pkg-gnome summarizing which packages needs to be uploaded, etc. It would be good to have a tool to create this list mostly automatically ... there are plenty of ways to improve things ! :) > > - an official way to follow interaction between mentors and sponsors is > > needed and actual mentors.debian.net/sponsors.debian.net are not > > enough for that > > Not in the current shape. Let me announce already that we are working on a > massive redesign of mentors.debian.net at the moment. We will rework the > interface to improve the communication between sponsors and mentors (yes, > it's badly needed, I know). Our approach is not a repository though. m.d.n > is mainly a place to upload and download packages - but not work on them > in parallel. Repositories are very useful when packages are co-maintained. > I'm working on multiple Debian projects where we would be lost without a > repository. But when it comes to sponsorship it's the > maintainers/sponsoree's task to maintain the package. I don't think the > sponsor should change the package at all. When sponsoring packages I don't > touch them. Even if there is a typo I "complain" to the package maintainer > and have the bug fixed. So I personally see a difference between > co-maintainership and sponsorship. Of course there are differences, but I don't see why we need to use a different tool. If the applicant just works in the SVN repository, even if he's the only one working on it you have an history of his work and you can see how he progressed. The sponsor interested in the package can see how the work is progressing even if the sponsor didn't send him an updated source package. Even for the NM process, it's great to be able to review in a single place all the work that he may have done. > > - we need to facilitate the work of sponsors because we're lacking > > sponsors > > Sponsoring isn't too hard. Potential sponsors just need to look at the Yes it is, otherwise you'd have more people doing it. Whatever can be simplified must be simplified : - checking that the .orig.tar.gz file used is the same than upstream - creating diff between current version and unstable/experimental - debdiff between packages - reviewing .diff.gz - i'm sure we can find many similar things We must create a tool that does the most important check automatically for us. > > - we need to let skilled external contributors maintain packages for us > > (when they don't want to become DD) > > I'm perfectly happy with a "permanent sponsoring relationship". Some DDs > seem to want every maintainer to become a DD. Becoming a DD is still a > long road and IMHO not needed. Once I have sponsored a package I know it's > technically okay and I know the sponsoree. Uploading a consecutive update > of the same package takes a few minutes only. I wished more sponsors would > offer such a relationship. When I had to look for sponsors myself a while > ago I saw sponsors come and go. And some packages didn't even make it into > Debian because nobody was interested. Permanent sponsoring should ideally also work with several sponsors... but this will work only if the sponsor can easily do all the check needed so that he can gain trust in your work. > > FWIW, I have an alioth project ready to be used : > > http://alioth.debian.org/projects/collab-maint/ > > What is the purpose of that project? Creating a repository? Or moving this > discussion to a mailing list there? It was meant to host the central repository needed. We can also use it to develop the tools needed... but we can decide to use it for other purposes if needed. The discussion should take place on usual Debian/Ubuntu lists IMHO. > As a conclusion... some of the aspects you proposed will be handled by the > new "version" of mentors.debian.net. In the future we plan to migrate > mentors.debian.net and sponsors.debian.net into a single service. We will > see how that works out. :) At least I'd like to monitor all efforts being > done because it would be sad to see m.d.n to become superfluous. It would be sad, that's why I invite you to share your plan about mentors.d.n and see how it can be intelligently merged in the scope of that project. The VCS should not be in contradiction with your work I think. > PS: Andreas Barth's posted about "Bits from the Darmstadt QA team meeting" a > while ago. I wrote him a lengthy mail but never got a reply. I wondered > what happened. What happened there ? Please see this web page full of videos: http://meetings-archive.debian
Re: Proposal for collaborative maintenance of packages
On Fri, 30 Dec 2005, skaller wrote: > > These things take time. > > Indeed. However change must start with awareness. We're quite aware of our limitations, but we can't make miracles. There's a lot to do and this thread proves that some people are willing to make things change for people like you. Had you taken the time to read the proposal which started this thread, you'd have discovered that it's very close to what you're vaguely proposing. We don't need more critics, we need : - good ideas to improve our tools and processes - time & people to code the new infrastructure (or the changes to the infrastructure) > Surely, but first there must be an idea of what the problems are > and what could be done. And in my opinion the DD's have far too > much 'paper work' to do, and their talents are not well deployed. Becoming "DD" implies some "paper work". But once someone is DD, there's no paper work any more ... but you keep speaking about this "paper work problem". So tell me what this prolem is ... > in the process -- the need to upload packages just to trigger > the autobuilder into rebuilding .. even when the sources have > not changed (tool change). I'm watching them do a whole lot of This problem has been adressed already, binary only NMU can be triggered by the release team. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
Hi Stefan, On Wed, 04 Jan 2006, Stefan Potyra wrote: > I'll just try to restart the discussion with a proposal: > Currently I maintain one package (min12xxw, see [1]) for ubuntu, have filed > an > ITP (#334093) in debian but haven't tried hard enough to find a sponsor yet. > > Since this package is quite small one, it might be well suited to just try > out > whether collaborative maintenance works/where possible problems might be. Ok, let's try it out. I can play the sponsor at the beginning. > > FWIW, I have an alioth project ready to be used : > > http://alioth.debian.org/projects/collab-maint/ > > So this could already be used? > If so, how could I upload the package/what would I need to do? The only thing which is "ready" is that there's a SVN repo available. I created a min12xxw directory there: SVN URL: svn+ssh://svn.debian.org/svn/collab-maint/ext-maint/min12xxw Web interface of the repo: http://svn.debian.org/wsvn/collab-maint/ext-maint/min12xxw/?rev=0&sc=0 Now, you should request an account on alioth.d.o and when you're done, please ask me to add yourself to "collab-maint". In parallel, you can familiarize yourself with svn-buildpackage and how to import your package in a SVN repository (try with a local SVN repository first, and later when you have the required rights on alioth, you'll do the same directly in the directory that I created). BTW, your import should create (svn-buildpackage offers several choices for the structure): .../min12xxw/trunk/... .../min12xxw/tags/ .../min12xxw/branches/ You can either import full sources or only the debian directory. I'd go for the full sources, but it's your call in the end. If you have questions, feel free to ask. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Collaborative maintenance, time to work
[Same crosspost than last time + debian-devel, but reply-to set to a new list] Hello everybody, following the previous mail on the subject, I revised a bit the proposal and started to write down the design of the infrastructure. I also created a mailing list where everybody interested to help should subscribe : [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/collab-maint-devel Please join and we'll continue the discussion over there (reply-to is set). Here are the wiki pages of the project : http://wiki.debian.org/CollaborativeMaintenance http://wiki.debian.org/CollaborativeMaintenance/Design I've started to write some code. There's not much but I have a module which is able to access a (local) subversion repository and extract the list of packages managed in the repository as well as the associated meta-information (version, distribution, urgency for now). We should aim to quickly create a web interface for this. I don't know yet how this interface should be made. I'm tempted to try Turbogears for this project but I'd welcome your suggestions. Cheers, Raphaël. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: need an example of using the keyword command to the PTS
Hi, On Wed, 22 Feb 2006, Amadan Korvin wrote: > OK i've been trying to get my subscriptions all configured properly to > [EMAIL PROTECTED] I've read and re-read and re-re-read the > help-file, and no matter what I do I can't get anything but the > default configuration to work. Which help file ? http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system is the authoritative documentation. > Can someone please type me up an exact (word for word) example of how > to, say, subscribe to package udev but only for keywords source-upload > and summary; and then how to reset the default keywords for my > address? (when i queried the pts it said currently my allowed keywords > are: (an empty list)) Easy solution: just use the web interface to subscribe. http://packages.qa.debian.org/u/udev.html In the form, select "advanced mode" instead of "subscribe", and you'll be able to select the keyword that you're interested in. Real answer : cat
Re: translation copyrights
On Tue, 18 Apr 2006, Neil Williams wrote: > On Tuesday 18 April 2006 9:26 am, Adriaan Peeters wrote: > > Hello, > > > > What is the correct way to handle copyright statements for translations? > > When the package has only a few translations, I can easily add the > > copyright statements to debian/copyright, but when the amount of > > translations increases, this quickly becomes messy. > > Use the GNU Translation Project and request that translators have signed the > TP disclaimer. > http://www.iro.umontreal.ca/translation/HTML/index.html This is going too far given the question. It's good to mention it but you should explain that it's enough to point to another file for the complete list of authors/translators if all files use the same license. This has recently been discussed on debian-devel. > > Can I refer to an (upstream provided) AUTHORS file, or is it imperative > > that I include all copyright statements in debian/copyright? Yes you can. Then you should just provide the AUTHORS/TRANSLATORS file along with the copyright file in /usr/share/doc//. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings about manpages in my packages
Hi, On Thu, 20 Apr 2006, Marco Bertorello wrote: > denyhosts-python2.3 > denyhosts-python2.4 > denyhosts-common > > the binaries are stored in packages -python2.X but the manpage (common > to alla packages) is stored in denyhosts-common. Why would you have a binary in -python2.3 *and* in -python2.4 ? And why can't you simply provide a single package an you make the choice to use either python2.3 or python2.4 ? I don't see the gain of having two versions of the same application just to work with two different python version... (it's different for Python modules because the user must be able to use the modules with the Python version of its choice) If your application works with python2.3 (default python version for the moment), then you use that and you're done. Once python2.4 is the default, you update your package to work with python 2.4 and you're done. And if you believe that the modules are useful for the end-user, then the current packaging make sense (bin and manpages in -common and modules in -python2.X). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linda warnings about manpages in my packages
On Thu, 20 Apr 2006, Steve Langasek wrote: > denyhosts-python2.3/2.4 do contain a python module. If and when the Great > Python Reorganization finally happens, this ought to be a single denyhosts > package depending on python (>> 2.3), python (<< 2.5). This can already be done with python-support (provided that the code isn't specific to a python version). > Since the package installs public modules, it seems to me that putting the > modules and the app in a single package is the wrong solution. We have plenty of modules which are packaged only for the current version of python in Debian and it's not "wrong". This wouldn't be worse. And the maintainer really needs to think if the modules are meant to be public or not ... because I see no documentation of the modules, so I wonder why we need to provide them for two python versions. > However, trying to make the application package auto-switch between two > different versions of python is also the wrong solution. Indeed. > In the meantime, the current packages have an RC bug, #361085, about the > fact that denyhosts-comon *does* include a binary that tries to support both > versions of python, but without appropriate dependencies to ensure a > consistent python configuration. Given the info that I've read here, if I were the maintainer I would have a single package "denyhost" with everything packaged for the default version. If I wanted to provide the modules for another python version I would use python-support. Check http://wiki.debian.org/DebianPythonFAQ for some info about how to use python-support. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-urwid - Console UI Library for Python
On Fri, 21 Apr 2006, Paul Wise wrote: > You are welcome to take over maintainership of it, or co-maintain it > with me, perhaps buxy can add you to the python-modules SVN. Given than Ian is the upstream author of the module, he is of course welcome in the team if he so wishes. Ian, just give me your alioth login if you are interested. > > I have packaged versions for python2.1, 2.2, 2.3 and 2.4, and I've > > made them available in an apt repository on excess.org. > > I think a better option would be to use python-support to make a single > deb that supports all python versions. I intend to do that once urwid > enters debian. More info here: I suggest on the contrary to do that before it enters Debian so that the ftpmaster do not create packages that will disappear shortly after and so that you don't have an upgrade path to handle. I did that for kid. And I mailed ftpmasters to tell them that they could reject the previous upload if that helped them (but my second upload was a new upstream version). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-urwid - Console UI Library for Python
On Fri, 21 Apr 2006, Ian Ward wrote: > >Given than Ian is the upstream author of the module, he is of course > >welcome in the team if he so wishes. Ian, just give me your alioth login > >if you are interested. > > Sure, but I am not a debian developer.. should I create a guest account > on alioth? Yes. > >I suggest on the contrary to do that before it enters Debian so that the > >ftpmaster do not create packages that will disappear shortly after and so > >that you don't have an upgrade path to handle. > > My understanding of debian packaging is quite limited. I tried to create > packages the same way I saw another python library packaged. If the > python-urwid package that enters the debian repositories is different > than what I have created, how do I transition people that are using my > repository to the new python-support way? Do I even have to? Packages won't conflict so the user may have both installed. We can consider adding conflicts to avoid this problem. > I would like to continue to support people that aren't running debian > unstable with packages for python2.1 (and python2.4 for ubuntu) The package with python-support would work with any python version. Ubuntu probably has python-support (in universe) so it shouldn't be a problem either. I'll let you check those details with Paul. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Templayer - HTML Templating Library for Python
On Thu, 04 May 2006, Paul Wise wrote: > They were mostly fine for the current python policy (although a bit > overkill). I'm looking forward to a more sane python policy, as > described in this email: > > http://lists.debian.org/debian-python/2006/01/msg00028.html > > Who is the python policy maintainer? All of us here on debian-python. Anyone can volunteer. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
On Tue, 30 May 2006, Goswin von Brederlow wrote: > > A downloader package is a bit of grey area; much like a typical > > "contrib" package, it has some more-or-less hardcoded string that > > points to non-free data; it does not, however, depend on anything > > outside of main to function (since main is enough to get a network up > > and running, and the web service, while not dealing with free > > software, is not Debian's concern as it is only between the user and > > the company publishing the data files). > > It depends on software not in debian to function properly. If the > firmware is no longer supplied on the firms webserver then the > donwload package stops working. Imho that is a clear dependency even > if it doesn't fall under the "Depends:" field. Contrib is effectively meant for wrapper on non-free stuff. But contrib is really needed when the wrapper stuff is the *main purpose* of the package. In the case concerning us, we have 10 lines of DFSG-free code that can be used to download non-free firmwares within a bigger DFSG-free package. For me it's no worse than putting the 10 lines of code in README.Debian, it serves really the same purpose. So my vote is "keep that little wrapper in the main package, it doesn't hurt". In fact, I go even further: I wish that the package use a low-priority debconf question (defaulting to "do not download") to let the user execute the wrapper at installation time. Of course, the question should warn the user that he's about to download non-free stuff. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
On Tue, 30 May 2006, Stephen Gran wrote: > Can't you just ship those ten lines in contrib, and the rest in main? > This may be archive bloat, but surely it's arch:all, so that minimizes > the bloat at least. I am not over fond of the freer-than-free holy > wars, but it does seem like this script is exactly the sort of thing > that contrib was designed for. Please think about what makes sense. Contrib has been designed for free stuff which are useless without non-free stuff. So when you create a wrapper package to install non-free fonts, it goes clearly in contrib because having that package in main would advertise too much the non-free fonts within Debian (the package name appears in synaptic, and the description clearly mentions non-free stuff) and we do not want that. However in our case, this wrapper script is *not* a package on its own. It's a helper script for a regular main package. The purpose of the script is not to encourage people to use non-free stuff but only to enable users which need those firmwares to download them... it's really not at the same level than the other wrapper for me. The "freer-than-free inquisitors" will explain that this is only rhetoric but for me it's not. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
On Tue, 30 May 2006, Bas Wijnen wrote: > Packages containing some contrib material, without which the package functions > well, can indeed go in main AFAIK. Yes. That's enough. If you agree on that why do you need after that to find a complicated explication on why finally this is not OK ? > However, if I understand the situation > correctly, this package is completely useless without the non-free firmware if > you happen to have a device which needs it. The fact that the package is > useful for other people is quite irrelevant: the download script is useless > for them anyway, irrespective of their attitude towards non-free software. No it's not irrelevant. You need to consider the package as a whole, it's not a package in one situation and another in a second situation. The split is not justified by any technical need and thus your reasoning is purely ideological. Technical reasons say the split is rather useless: creating a new source package from scratch for a 10 line script is waste of our resources. So the decision is entirely up to the maintainer. He can integrate it in the main package. However if he decides to create a dedicated package for the wrapper, then he needs to create a new contrib source package. > Then again, this sounds pretty much like a thing for debian-legal. :-) Not at all. We all know what is DFSG and what is not in this case. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
On Thu, 08 Jun 2006, Bas Wijnen wrote: > Because the package (as I understood it, I don't actually know the package) > doesn't actually function at all for some people. That's not because they > aren't interested in it, it's because they need non-free stuff to make it > work. Indeed and our job is to help our users who are in this situation. They want to use their hardware, we have to tell them how they can get it to work. Hiding the script in contrib doesn't help our users. > > The split is not justified by any technical need and thus your reasoning > > is purely ideological. > > Of course it is! There is never a technical reason to put anything in contrib > or non-free. That's all ideological. You make it sound like ideological > arguments are not "real", and are less important than technical ones. I > strongly disagree with that. Debian is an organisation which provides > software which is both technically and ideologically very good. Both of these > properties should be protected. Putting things in main which really belong in > contrib "because there's no technical argument for putting them in contrib" is > damaging the image of Debian IMO. It makes people think we only care about > technical matters. If that was the case, contrib wouldn't exist at all. Well contrib serves an ideological purpose that I share: not cluttering the package database of people who are not interested in installing non-free software (because they will have to install something non-free to make use of contrib). However extracting a script from a package in main in a new contrib package doesn't make any sense. You're not thinking what's best for the user and for Debian, you're only applying a narrow-minded interpretation of the definition of contrib. > I wasn't suggesting a new source package. I assumed (and this has been > confirmed in this thread) that it is possible to create a contrib binary > package from a source package in main. Where has this been confirmed? I was convinced of the contrary since main, contrib and non-free are top directories in the pool and I expected them to be self containing (sources+binaries). > > So the decision is entirely up to the maintainer. > > Of course it is. And if the maintainer comes here to ask what to do, we're > going to give advice. Contradictory advice... so it's better (when possible) to come to a consensus. > > Not at all. We all know what is DFSG and what is not in this case. > > It is totally clear that for some people this package depends on (as in: > doesn't do anything useful without) non-free things. IMO that makes it > contrib, but others don't seem to agree. In case of such (theoretically > based) disagreements I think of debian-legal. That thought can be completely > misplaced of course. :-) There's no notion of "contrib for some" and "main for others". So the package is in main and should provide the helper script to make it useful for the largest number of users. In any case -legal is not the moral authority of Debian and since the problem is not license related, -legal is not a list to consult. -devel would be more appropriate but we would probably have the same discussion as here so a general resolution would be the only way to decide. :-) Actually a new official definition of contrib might be welcome since we're having discussion about it very regularly (remember ndisplayer?). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UNable to configure my package
On Wed, 26 Sep 2007, varun_shrivastava wrote:
> i have made a package which is a simple gtk application.
> it depends on gtk-directfb-2.0.so.0 ,
> i included this library in the depends field in control file.
Please ask on debian-mentors, it's made for people who learn packaging.
> after creating the package when i try to install it using dpkg -i
> it displays following error
>
> dpkg: dependency problems prevent configuration of clock:
> clock depends on libgtk-directfb-2.0 (>= 2.2); however:
> Package libgtk-directfb-2.0 is not installed.
>
> the package is installed at /usr/local/lib but i did a make install for this
> library, i haven't installed it from a gtk-directfb package. Also i found
You need a _package_ libgtk-directfb-2.0 and not just a manually installed
library.
This library is packaged as libgtk-directfb-2.0-0 (note the -0 at the end
that you don't have) in Debian. Furthermore, dependencies on libraries
are automatically generated and thus you shouldn't hardcode the name of a
library in the Depends line (but rather put ${shlibs:Depends}).
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build-indep and buildd
On Wed, 01 Feb 2012, Mathieu Malaterre wrote: > > In summary, before upload > > > > 1. run dpkg-buildpackage -b to reproduce buildd behavior > > Looks like buildd are using `dpkg-buildpackage -B` by the way Yes, -b would not help, you need -B. But as has been said, you must wait for the next dpkg release until the unstable buildd will start using the build-arch and build-indep targets. Right dpkg-buildpackage will always use "build". Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201194159.gb20...@rivendell.home.ouaza.com
Re: Getting rid of control messages revisited
Hi, On Thu, 24 May 2012, Arno Töll wrote: > [*] jwilk looked into the code and it /seems/ to me, the "bts" > subscription does not contain control messages, whereas "bts-control" > control does. Can anyone verify this? I confirm this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528194352.gt18...@rivendell.home.ouaza.com
Re: dpkg-buildpackage and debhelper: removed debian/tmp
Hello, On Fri, 13 Jul 2012, Michael Gissing wrote: > Hi all, > > I'm not sure whether that's the suitable mailing list, so if theres > a better one I would really appreciate a hint. The correct list is debian-mentors@lists.debian.org. debian-dpkg is to discuss the development of dpkg itself. (Keeping lots of context for debian-mentors) > I'm trying to build a package using dpkg-buildpackage and debhelper. [...] > dh binary >dh_testroot >dh_prep > rm -f debian/mypackage.substvars > rm -f debian/mypackage.*.debhelper > rm -rf debian/mypackage/ > rm -rf debian/tmp >dh_installdirs > install -d debian/mypackage > install -d debian/mypackage/usr/bin > debian/mypackage/var/mypackage/nv debian/mypackage/var/log/mypackage >dh_auto_install >dh_install > cp -a debian/tmp/bin/mybin debian/mypackage/usr/bin/ > cp: cannot stat `debian/tmp/bin/mybin': No such file or directory > - > > It's obvious that dh_install can't find the file in debian/tmp > because dh_prep just removed the dir three steps before. That's > somehow strange, since dh_install will look for files in debian/tmp > per default. > > Do I miss something? Why does dh_prep remove a dir that dh_install > will use per default? dh_auto_install should populate debian/tmp/ for you. And this one appears after dh_prep. So your real problem is likely that dh_auto_install is not doing anything useful currently. (If your source package has a single binary package, then debian/tmp is not used, the files are directly installed in debian/, so the above remark assumes that you have a source package with multiple binaries) Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120713125426.gf7...@rivendell.home.ouaza.com
Bug#684106: Bug#682274: New LedgerSMB Debian package, v1.3.21-1
Hi, On Tue, 07 Aug 2012, Christian PERRIER wrote: > Just in case Raphaël can't upload, I can do it. But I'd prefer doing > so as a backup only and keep Raphaël as main sponsor (because he is, > IIRC, a user of LedgerSMB in hiw own business). I'll try to take care of it but I'm not using LedgerSMB, I'm using sql-ledger currently. > As this is a new upstream version, a good argument (with patches, > etc.) has to be prepared for the release team to have elements for > their decision about allowing it in wheezy. I think a pre-approval by > them would even be preferrable. James, how does the debdiff look like between the wheezy and sid versions? In any case, the main justification is the security fixes and the fact that it's a leaf package. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120807070945.gd21...@rivendell.home.ouaza.com
Bug#684106: New LedgerSMB Debian package, v1.3.21-1
Hi, On Mon, 06 Aug 2012, Robert James Clay wrote: >Besides uploading the new package version to the Mentors site, I went > ahead & submitted a Request for Sponsor bug as well (#684106 [1]) Here's my review of your package: In control: Recommends: default-mta | mail-transport-agent, texlive-latex-recommended, libopenoffice-oodo c-perl, - libmath-bigint-gmp-perl, libparse-recdescent-perl, libtemplate-plugin-latex-perl -Suggests: postgresql, lpr, libnet-tclink-perl, latex-cjk-all, - libimage-size-perl + libmath-bigint-gmp-perl, libparse-recdescent-perl +Suggests: postgresql, lpr, libnet-tclink-perl, latex-cjk-all This change is not documented in debian/changelog. Why did you remove those recommendations/suggestions ? In preinst: +# Set old_version variable for use later in the script. +old_version=$2 You do not seem to use $old_version later. Drop it. + if dpkg --compare-versions $2 lt 1.3.19-1; then +# If symbolic links for css and templates directories to the +# /var/lib/ledgersmb exist, then remove them. +if [ -h "/usr/share/ledgersmb/css" ]; then +rm -f /usr/share/ledgersmb/css +fi +if [ -h "/usr/share/ledgersmb/templates" ]; then +rm -f /usr/share/ledgersmb/templates +fi + fi 1.3.19-1 doesn't appear in the changelog and has never been released to Debian. You should better use 1.3.21-1 as version for this check. Also please don't use 2-spaces indent, they are unreadable. Use at least 4 spaces. And be consistent. I think you have duplicated some information in debian/NEWS too (the para starting with "Empty language specific" in 1.3.21-1 is almost the same as the one in 1.3.18-1). Please fix all those issues and I will upload the updated package. Now concerning the inclusion of this updated package in wheezy, my experience of Debian led me to believe that you will have a hard time convincing release managers to let this update in. The fact that security updates are mixed in new upstream releases mean that there's no "stable branch" that can be safely maintained over the course of 3 years. They could possibly suggest you to remove the package instead since it can't be supported in stable. Thus you should maybe ask upstream how long they intend to support the 1.3 branch and whether they are willing to provide targetted security fixes for the version released in Debian in the case of future security issues? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120808222049.ga7...@rivendell.home.ouaza.com
Bug#684106: New LedgerSMB Debian package, v1.3.21-1
On Thu, 09 Aug 2012, Robert James Clay wrote: >Also; my inclination now is to do a 1.3.21-2 package with any > necessary changes and upload that (instead of removing the existing > 1.3.21 package on mentors and uploading a new version of it after any > neccessary corrections). Doing it that way does mean that I need to > take care to include the information about the closed bugs with > 1.3.21-1. You don't need to move bug closure information. I must just take care to build it with -v1.3.18-1 to include both changelog entries. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120809130006.gd14...@rivendell.home.ouaza.com
Re: dh machinery and module how to export only given symbol
Hi, On Sat, 25 Aug 2012, Jerome BENOIT wrote: > Hello: > > I have to build a module that exports only symbol with a given prefix: > in the pre-dh debian/rules , something as > > CFLAGS="$(cflags) -Wl,--version-script,debian/.version" > > was use. I cannot figure out how to proceed within the dh machinery. With debhelper in compat 9 mode, it will set the various variables by using dpkg-buildflags. Thus you can use the facilities of dpkg-buildflags to extend such variables. See man dpkg-buildflags. export DEB_CFLAGS_MAINT_APPEND=... This is the recommended way nowadays. But in truth, setting and exporting variables should just work since dh will not overwrite existing environment variables. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120825053908.ga1...@rivendell.home.ouaza.com
Bug#684106: RFS: ledgersmb/1.3.21-2
Hi, On Thu, 30 Aug 2012, Bart Martens wrote: > Hi Robert, > > Have you noticed that there's a newer upstream release ? > http://sourceforge.net/projects/ledger-smb/files/ He did, but as he wanted to try to get an updated version into wheezy (there are serious issues with the current version in wheezy), he decided to stay on an older version with less upstream changes. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120830094805.ge19...@rivendell.home.ouaza.com
Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
Hi, On Wed, 10 Oct 2012, Jasmine Hassan wrote: > For instance, I'm packaging Compiz 0.8.8, for MATE desktop. This, at > least initially, requires a lot of code substitutions, and quite a few > file/dir renaming. (ex.: gnome -> mate, gconf -> mateconf, metacity -> > marco, etc.) I use a home-brewed migration script to generate actions > for that. Compiz has not been forked but you have to patch it heavily because Gnome/Gconf/Metacity have been forked? Is that right? In that case, I truly believe that MATE should fork Compiz as well and provide clean upstream sources (even if they are automatically generated by a script that does the renames and all). > huge, unnecessary patch. I might as well modify the upstream tarball > and use that as the orig, which, of course, is not proper. Why not? Were you intending to integrate your work in Debian's official compiz package? (Somehow I doubt that the maintainer would be interested to clutter his packaging to accomodate MATE) Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121010064924.ga24...@x230-buxy.home.ouaza.com
Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
On Wed, 10 Oct 2012, Jasmine Hassan wrote: > Exactly, and gnome 2.x is no longer maintained, nor is Compiz 0.8.8, > last in release 0.8.x from April 2011 So you have no other solution than to take over upstream maintenance. > > In that case, I truly believe that MATE should fork Compiz as well > > and provide clean upstream sources (even if they are automatically > > generated by a script that does the renames and all). > > That's what I'm doing. Wolfgang Ulrich has also done similar, for > redhat/fedora http://forums.fedoraforum.org/showthread.php?t=276286 You should really collaborate on upstream maintenance and differ only in the packaging. > >> huge, unnecessary patch. I might as well modify the upstream tarball > >> and use that as the orig, which, of course, is not proper. > > > > Why not? > > In case someone decides to take over maintaining the package in > unstable (and that it returns to testing), will collide, and > apt-pinning is a pain for LMDE devs/maintainers. You certainly should not take over the compiz package. You should introduce "compiz-mate" that builds entirely new binary packages. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121010073130.gr23...@x230-buxy.home.ouaza.com
Bug#691711: [Pkg-sql-ledger-discussion] New LedgerSMB Debian package, v1.3.23-1
On Sun, 28 Oct 2012, Robert James Clay wrote: > >A new version of the LedgerSMB package, v1.3.23-1, is now available > > and has been uploaded to the Mentors site pending a sponsor. > >Raphael; if you're able to take a look at it, I'd appreciated it! Do you want to upload it to unstable or to experimental ? If to unstable, then you should probably close your current unblock request as this version is even more unlikely to be unblocked. Please let me know. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030195859.ga10...@x230-buxy.home.ouaza.com
Re: Maintainer address for collab-maint team maintained packages
On Mon, 19 Nov 2012, Arno Töll wrote: > Thing is, you can't use the QA forwarder because it relies on your > source control field to learn about actual forwardings. If you would add > right that address, the result would be an infinite loop because you > would essentially forward mail to @packages.debian.org to > @packages.debian.org. I hope it is clear why this won't work. Yeah, but this should be easily fixable... we can fix the script generating the alias to strip those emails (/srv/packages.debian.org/bin/build-maintainerdb). The problem lies elsewhere. The BTS, dak and many Debian services mail the address listed in the Maintainer field *and* send a copy to the PTS. This includes packages.debian.org which mail the Maintainer (not Uploaders) and the PTS. If you put @packages.debian.org as Maintainer, the flow of email is duplicated. Once via @packages.debian.org and once directly via the PTS. This is also fixable but it's less easy to do it in a clean way, except by teaching this special case to all services... which is painful. It's one of the reason which pushed me to start http://dep.debian.net/deps/dep2/ but alas I'm too busy to go forward with it currently. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121127145422.ga29...@x230-buxy.home.ouaza.com
Re: Bug#651606: RFP: gitlab -- git project/repository hosting management app
[ CCing debian-mentors in the hope to find someone who is willing to package this software ] On Sat, 10 Dec 2011, Bernd Zeimetz wrote: > Package: wnpp > Severity: wishlist > > * Package name: gitlab > Version : 1.2.0 (+git...) > Upstream Author : Dmitriy Zaporozhets > * URL : http://gitlabhq.com > * License : MIT > Programming Lang: Ruby > Description : git project/repository hosting management app > > Ruby on Rails based application to manage your own git > project/repository hosting, using gitosis or gitolite to manage ssh > access. FWIW, there are some unofficial Debian package at https://github.com/gitlabhq/gitlab-public-wiki/wiki/GitLab-Debian-packages-%28unofficial%29 but they are far from perfect since many gems are packaged in a giant gitlab-bundle. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121219134400.ga26...@x230-buxy.home.ouaza.com
Re: Bug#651606: RFP: gitlab -- git project/repository hosting management app
On Wed, 19 Dec 2012, Daniel Martí wrote: > Is there any packaging team I should contact? Should I start using > collab-maint on anonscm.debian.org for its packaging right away? The packaging work will surely require you to create a bunch of ruby gems so you might want to joint the ruby extras team. http://wiki.debian.org/Teams/Ruby But for gitlab itself, collab-maint is certainly OK. > On a side note, I'm neither a DD nor a DM yet - a sponsor would be needed. I think Paul just volunteered to sponsor ;-) Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121219150900.ga6...@x230-buxy.home.ouaza.com
Re: (debian control) error with dpkg-gencontrol
On Wed, 24 Jun 2009, xiangfu wrote: > Hi > I want to be a New Maintainer, so I follow "Debian New Maintainers' Guide " > but when a use "dpkg-buildpackage -rfakeroot" Please use debian-mentors@lists.debian.org for your packaging questions. > dpkg-gencontrol: error: must specify package since control info has many () It's likely that debian/control is broken. > here is the control file : > > http://code.google.com/p/pi-project/source/browse/trunk/flash-tool/debian/control You lack an empty line between line 7 and 8. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DEB_BUILD_OPTIONS=parallel=n work not as expected
On Sun, 06 Dec 2009, Erik Schanze wrote: > Hi, > > [Sorry for crossposting to debian-dpkg, but perhaps they could clarify this. > Orig. post was: http://lists.debian.org/debian-mentors/2009/12/msg00075.html] dpkg plays zero role in that problem, -devel would have been more appropriate. > As far as I understand, the substitution comes from "make" itself > and it occurs in every sub-make during parallel build. Yes, that's the reason we use $(MAKE) and not "make" IIRC. > But is it the intended behaviour, that the make call in "build" target will > run with option "-j" without any number? > Because this will end in a build run with unlimited jobs, or did I miss smth.? I don't know but $(MAKEFLAGS) doesn't need to be given on the make command line, AFAIK it's implicit so try removing it in your invocation. Or maybe the 2 is implicitly respected because it corresponds to the number of fds given in --jobserver-fds. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: flow of things rules/debhelper
Hi, On Mon, 05 Apr 2010, Osamu Aoki wrote: > On Mon, Apr 05, 2010 at 03:30:50PM +0200, Mike Hommey wrote: > > > The commands listed below are run twice, once with the "-a" option (in > > > binary-arch) and once with the "-i" option (in binary-indep): > > > > Actually, it doesn't. dh binary just runs whatever sequence is necessary > > for the binary target, starting from where it ended last, running > > without even -i or -a. > > dh binary-arch will do the same, but with the -a argument. > > dh binary-indep will do the same, but with the -i argument. > > ... That was what I think too. > > It was updated by raphael to current form: [...] > His thought was to present a simpler story to the novice, I guess. > > Should i revert this? I saw you changed it back, thanks, I wanted at least to avoid having the same list multiple times. And if one wanted to be picky, you could note that the sequence for binary-indep does not include dh_strip, dh_makeshlibs and dh_shlibdeps. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100407072119.ge10...@rivendell
Re: flow of things rules/debhelper
On Wed, 07 Apr 2010, Osamu Aoki wrote: > What is needed is documentation on dh_listpackages and its usage to sort > out binary-indep and binary-arch difference for override commands. > > Otherwise, buildd may fail if they only install Build-Depends: (I vaguely > remember, they install Build-Depends-Indep: too. But you never know.) I think you are confusing issues here. For override commands, the -i and -a options of debhelper are implicitly passed through the environment variable DH_INTERNAL_OPTIONS, that't the only difference I know between overrides targets called in binary-indep vs binary-arch. buildd only install Build-Depends but they also build packages with "dpkg-buildpackage -B" so that they call "debian/rules binary-arch" (and not binary or binary-indep). So everything is fine on that regard AFAIK. The hack using dh_listpackages that you quote might not even be needed nowadays. If a commands receives -p and has contradictory options in DH_INTERNAL_OPTIONS, it will do nothing just like expected: ┏rivendell:~/tmp/circuslinux-1.0.3 ┗(522)$ DH_INTERNAL_OPTIONS="-i" dh_listpackages -pcircuslinux dh_listpackages: No packages to build. ┏rivendell:~/tmp/circuslinux-1.0.3 ┗(523)$ DH_INTERNAL_OPTIONS="-a" dh_listpackages -pcircuslinux circuslinux ┏rivendell:~/tmp/circuslinux-1.0.3 ┗(524)$ dh_listpackages circuslinux circuslinux-data Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100407125741.gb16...@rivendell
Re: flow of things rules/debhelper
On Wed, 07 Apr 2010, Osamu Aoki wrote: > But are you sure this holds for dh_auto_build. If buildd only install > Build-Depends and dh_auto_build initiate doc building using latex listed in > -indep, then we are in trouble. As I understand, it usually run $(MAKE) for > any case. So if doc package needs latex-thingy in Build-Depends-indep, > override_dh_auto_build needs to take care -i and -a issue providing separate > target to $(MAKE) = dh_auto_build as: dh_auto_build doesn't do something "per binary package", it does something once for the whole source package. So I don't understand what you really expect here. And it's a know limitation of dpkg-buildpackage that we have only "debian/rules build" when we should have build-arch and build-indep just like for binary. Currently Build-Depends needs to list the dependencies for the full build, independently of whether or not we are using debhelper. > override_dh_auto_build: > ifneq (,$(findstring one-for-arch, $(shell dh_listpackages))) > dh_auto_build -- build-one-for-arch > endif > ifneq (,$(findstring one-for-doc, $(shell dh_listpackages))) > dh_auto_build -- build-doc > endif > > We can not use conditional on DH_INTERNAL_OPTIONS here to change behavior of > override_dh_foo. This is because, debhelper maintainer Joey Hess told me so. > He specifically pointed to this dh_listpackages. Right, this is still a very specific corner case that is not worth documenting in the maint-guide that targets beginners. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100407142444.ga18...@rivendell
Indicator applets and related packages
[ Bcc debian-mentors as some prospective DD might be interested in packaging those ] Hello, I would like to be able to use ubuntu's indicator applets in Debian but very few of the required packages are in Debian (only libindicator is available). Here are some of the design pages if you don't know what this is all about: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators https://wiki.ubuntu.com/MessagingMenu https://wiki.ubuntu.com/MeMenu The missing source packages are AFAIK: - libdbusmenu https://launchpad.net/ubuntu/+source/libdbusmenu (no RFP/ITP known) - libindicate https://launchpad.net/ubuntu/+source/libindicate RFP: http://bugs.debian.org/560122 - indicator-applet https://launchpad.net/ubuntu/+source/indicator-applet RFP: http://bugs.debian.org/534556 - indicator-messages https://launchpad.net/ubuntu/+source/indicator-messages (no RFP/ITP known) - indicator-application https://launchpad.net/ubuntu/+source/indicator-application (no RFP/ITP known) - indicator-session https://launchpad.net/ubuntu/+source/indicator-session (no RFP/ITP known) - indicator-me https://launchpad.net/ubuntu/+source/indicator-me (no RFP/ITP known) - indicator-sound https://launchpad.net/ubuntu/+source/indicator-sound (no RFP/ITP known) - in the near future: indicator-network https://launchpad.net/indicator-network And also several plugins/extensions to various piece of software: - evolution-indicator https://launchpad.net/ubuntu/+source/evolution-indicator And some of those in Qt/KDE variants: - libindicate-qt https://launchpad.net/ubuntu/+source/libindicate-qt - https://launchpad.net/plasma-widget-message-indicator I contacted Ted Gould of Ubuntu/Canonical to ask him whether he would like to maintain some of those packages within Debian. If yes, I'll sponsor him (if you want to be the sponsor instead of me, please say so). I hope we can find maintainers for all those. Should they be maintained within the Debian Gnome team ? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614073602.ga25...@rivendell
Re: RFS: taskcoach - useful task manager - new - python app
On Sun, 07 Nov 2010, Alejandro Garrido Mota wrote: > My motivation for maintaining this package is: I use this application > like my personal task manager,. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/t/taskcoach > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/t/taskcoach/taskcoach_1.2.2-1.dsc Just downloaded it to have a quick look and noticed that it build-depends on libcurl3-dev. Why? Even for an "initial release", you can put some comments in debian/changelog explaining your initial packaging choices and the unusual work you did (writing/applying a patch falls in this category). Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101108075448.gg20...@rivendell.home.ouaza.com
Re: RFS: taskcoach - useful task manager - new - python app
On Mon, 08 Nov 2010, Raphael Hertzog wrote: > On Sun, 07 Nov 2010, Alejandro Garrido Mota wrote: > > My motivation for maintaining this package is: I use this application > > like my personal task manager,. > > > > The package can be found on mentors.debian.net: > > - URL: http://mentors.debian.net/debian/pool/main/t/taskcoach > > - Source repository: deb-src http://mentors.debian.net/debian unstable > > main contrib non-free > > - dget > > http://mentors.debian.net/debian/pool/main/t/taskcoach/taskcoach_1.2.2-1.dsc > > Just downloaded it to have a quick look and noticed that it build-depends > on libcurl3-dev. Why? > > Even for an "initial release", you can put some comments in > debian/changelog explaining your initial packaging choices and the > unusual work you did (writing/applying a patch falls in this category). Also /usr/share/pyshared/taskcoachlib/thirdparty contains python code grabbed from third parties, i.e. those are embedded libraries and we try to avoid those in particular if they have already been packaged separately in Debian. You want to check those one by one and use the officially packaged variant when it exists (i.e. replacing the files with symlinks towards the official package). Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101108081637.gh20...@rivendell.home.ouaza.com
Re: RFS: clipit
On Fri, 12 Nov 2010, Cristian Henzel wrote: > dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided > if "debian/clipit/usr/bin/clipit" were not uselessly linked against it > (they use none of its symbols). > > but this last one is unnecessary, because my program actually uses > functions from libpthread.so (pthread_exit), so it needs that library... Hum, libc.so.6 also has that symbol (and dpkg-shlibdeps finds it there first), that's why dpkg-shlibdeps thinks it's not necessary. But I hear those symbols on libc6 are weak and thus the one provided by libpthread are used. Thus this warning is rather bogus apparently. Would you please file a bug report against dpkg-dev for this? Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101112091608.ge22...@rivendell.home.ouaza.com
Re: RFS: clipit
Hi, On Fri, 12 Nov 2010, Cristian Henzel wrote: > thanks for your reply! I have also tried removing the reference to > pthread.h in my program, hoping that it would take the symbols from > libc, but I still got the same warning from dpkg-shlibdeps. > So, should I put the reference to pthread back in and leave it like that > (with the warning) and submit the bug against dpkg-dev? Actually the problem is more complex apparently. You don't need to link it to libpthread unless you call pthread_create somewhere. So you need to fix the options passed to the linker to drop the -lpthread (the library linked are unrelated to the include you use, but if you can drop the include and it still builds it probably means you don't need the library for real and you can drop it from the linker command line). So it's not a bug on dpkg-shlibdeps as I first suspected. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101112095054.ga4...@rivendell.home.ouaza.com
Re: RFS: clipit
Hi, On Fri, 12 Nov 2010, Cristian Henzel wrote: > P.S. I find it odd that it includes the package even if there's no > referece to it and I also use -Wl,--as-needed... Maybe -Wl,--as-needed is not smart enough to cover this case. Entirely dropping the -lpthread is the only way to fix this apparently. That said the dpkg-shlibdeps warning is harmless and it's not a big deal if it stays in your build log. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101112124801.ga6...@rivendell.home.ouaza.com
Re: RFS: clipit
On Fri, 12 Nov 2010, Cristian Henzel wrote: > If it's a harmless warning and the rest of it is fine, could it get in > the repos like this? Sure, this warning is not a reason to block an upload. Many packages in the archive have this kind of warnings. They are not "bugs" but things that can be improved. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101112134753.ga8...@rivendell.home.ouaza.com
Re: RFS: clipit
Hi, On Fri, 12 Nov 2010, Cristian Henzel wrote: > > Sure, this warning is not a reason to block an upload. Many packages in > > the archive have this kind of warnings. They are not "bugs" but things > > that can be improved. > > ok, so is there anything else that I need to do, or will you upload it? I responded on a specific point (which concerns me since I'm maintaining dpkg-shlibdeps), I have not looked the rest of the package and I don't intend to do it, sorry. Someone else should be sponsoring it. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101112154455.ga23...@rivendell.home.ouaza.com
Re: Debconf in non-interactive mode
On Sat, 20 Nov 2010, Boyd Stephen Smith Jr. wrote: > In <20101120223808.ga15...@mea.homelinux.org>, Mats Erik Andersson wrote: > >Question: Is there some mechanism I can use in the postinst > > script that lets me determine whether the upgrade > > is being conducted in non-interactive mode? > > First, you should *assume* non-interactive mode. > > To test for interactivity, you could try opening /dev/tty.[1] It's not This a good answer to the question asked but the question is wrong. Or at least it doesn't give us enough information to understand the nature of the problem. We have debconf to handle user-interaction and the script should not have to care if someone typed the answer or if it's the default answer recorded in the debconf template. Why is the postinst failing in non-interactive mode? Are you using some home-made stuff instead of debconf? If not, why is the default debconf answer not working? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101121082549.gd11...@rivendell.home.ouaza.com
Re: .changes files without source packages
Hi, On Fri, 03 Dec 2010, Daniel Lazzari wrote: > I have a collection of SDK packages we are building using dpkg -b that > we need to distribute to our external developers. Because some of the > libraries come from proprietary code, and others from assets, they > should only be binary packages, not source packages. When trying to Using dpkg -b directly is still not the right way to build a package. If you don't want to distribute a source package, that's fine don't distribute it. But a debian binary package should always be built from source package, it's the best way to create a policy compliant package because you will use the same tools that all Debian developers are using to create official packages. And then you will have no problem with dpkg-genchanges... it's only designed to work from within an unpacked source package. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101204210313.gf18...@rivendell.home.ouaza.com
Re: .changes files without source packages
On Sun, 05 Dec 2010, Paul Wise wrote: > On Sun, Dec 5, 2010 at 5:03 AM, Raphael Hertzog wrote: > > > Using dpkg -b directly is still not the right way to build a package. > > If you don't want to distribute a source package, that's fine don't > > distribute it. But a debian binary package should always be built from > > source package, it's the best way to create a policy compliant package > > because you will use the same tools that all Debian developers are using > > to create official packages. > > > > And then you will have no problem with dpkg-genchanges... it's only > > designed to work from within an unpacked source package. > > It is very unlikely Daniel's work is intended for the Debian archive, > so there is no need for him to create packages in policy compliant, > normal or standard way. Debian policy compliant is our definition of a "good package". And I bet everybody wants to create good packages. So let me disagree with you on this one. :-) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101206074321.gb32...@rivendell.home.ouaza.com
Re: Conf files and static files in a deb package
Hi, On Sun, 16 Jan 2011, pablo platt wrote: > I'm using dh_help to build a package template and trying to follow the > debian packaging guide for creating a binary package. Please ask your packaging questions on debian-mentors@lists.debian.org. This list is for developing dpkg. Just a quick hint for you though: > How do I tell debuild which file is a conf file and should go for example to > /etc/mypkg.conf ? [...] > I also don't understand how to include static files in the package. man dh_install Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110116163510.ge17...@rivendell.home.ouaza.com
Re: HOWTO: Source a common shell script between DEBIAN/config and DEBIAN/preinst
Hi, your questions are probably better answered on debian-mentors@lists.debian.org. On Tue, 18 Jan 2011, harish badrinath wrote: > Given that i was told that you can deterministically determine which > file would run first DEBIAN/control _or_ DEBIAN/preinst, I have this > following query. You meant DEBIAN/config (and not control). This information is true but why do you care about the preinst ? The config script will be called before the "postinst" and that's all that usually matters. > I want to source a common file between these two scripts to ensure > that if the package cant automatically detect sane values, it prompt > the user for input as the last resort. The "DEBIAN" directory is for meta-information, it's definitely not a good place to store a shell library that shall be shared between a config script and a preinst script. > The values given itself are > trivial in nature, but if not done correctly would make the system > unusable by locking all the users out of the machine. When do you expect to use those values? Usually we use values to update a configuration file and we do that in the postinst. Without the configuration file the service/program is inactive and should definitely not lock all users out of the machine. > ./DEBIAN/preinst > #!/bin/bash > # Source debconf library. > . /usr/share/debconf/confmodule > . test > > sayhello "sekon:preinst" "ohai" You have no guaranty that debconf is available when the preinst is run. You should not use debconf as if it was there for sure. Note however that if you run debconf here, it will execute the config script if it has not yet been run. (Your log showed the config script being executed) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118075243.gb31...@rivendell.home.ouaza.com
Re: common source package for use in Debian and Ubuntu
On Tue, 18 Jan 2011, Joachim Wiedorn wrote: > I want to realize the idea of a debian directory usable for Debian *and* > Ubuntu. It works with a switch in the clean target of debian/rules: Great! > ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes),yes) > @echo modify changelog and control file for vendor Ubuntu: > cat debian/control.Ubuntu >debian/control > cat debian/changelog.Ubuntu debian/changelog.base >debian/changelog > else > @echo modify changelog and control file for vendor Debian: > cat debian/control.Debian >debian/control > cat debian/changelog.Debian debian/changelog.base >debian/changelog > endif No so great... see below. > Now my questions: > > 1. is this a good way for switching contol file? >It must switch the maintainer lines because Ubuntu has another policy. No. Ubuntu doesn't change maintainer fields if the package in Ubuntu doesn't have modifications compared to Debian. If you do the work to have all Ubuntu specific changes in common source package there's really no need to have a different control file. > 2. this way is not the best for the changelog file because every change >in debian/changelog must copied into the both other changelogs. >Does anyone know a better way ? Again, the same changelog file is used when there's a common source package. No customization needed here. > 4. Can I let all Ubuntu changelog parts (beside the very last) inside >the changelog of Debian? Then changelog.Debian would be unnecessary. It's quite common to have some bits of Ubuntu history in official Debian packages... but mainly for packages created by Ubuntu and then integrated in Debian. If you want to keep the Ubuntu history now that you create a common source package, why not. It's up to you I guess. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118080335.gc31...@rivendell.home.ouaza.com
Re: common source package for use in Debian and Ubuntu
On Tue, 18 Jan 2011, Joachim Wiedorn wrote: > Ok, but how should I manage the last changelog entry (in time frame and > in handling)? > > Debian should have e.g: >lilo (1:23.1-1) unstable; urgency=low > and then Ubuntu should have e.g: >lilo (1:23.1-1ubuntu1) natty; urgency=low > >lilo (1:23.1-1) unstable; urgency=low > > and the last Ubuntu changelog usually have some ubuntu specific bug fix > entries. Or should I write the ubuntu bugfixes into the Debian part of > changelog? Packages can be synced into Ubuntu without having any Ubuntu-specific changelog. Look for example: http://changelogs.ubuntu.com/changelogs/pool/main/s/smartmontools/smartmontools_5.39.1+svn3124-2/changelog It's a normal Debian changelog, yet it's part of Ubuntu. So use your changelog like usual and yes you should put Ubuntu bugfixes and Debian bugfixes in the same changelog entry. Don't create fake Ubuntu entries. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118204229.gb1...@rivendell.home.ouaza.com
Re: RFS: ncmpcpp (updated package)
Hi, On Fri, 07 Jan 2011, Damien Leone wrote: > The package can be found here: > - URL: http://debian.fensalir.fr/ncmpcpp/ > - dget http://debian.fensalir.fr/ncmpcpp/ncmpcpp_0.5.6-1.dsc Uploaded. A few comments to fix for the next time: - you build-depend on libcurl4-dev but it's a virtual package, you should instead build-depend on "libcurl4-gnutls-dev | libcurl4-dev" to give a hint to the build daemon as to which version of the package they are supposed to use... (if it's libcurl4-nss-dev that is preferred then update the dependency accordingly). - it's weird to add an upstream changelog in a debian patch, you should try to find a way to have upstream generate that changelog automatically. For dpkg we have modified "make dist" to generate the changelog from the git repository. Maybe you could propose a patch for this to upstream? - this upload changes the timestamp of a previous changelog entry: - -- Damien Leone Thu, 09 Dec 2010 15:31:32 +0100 + -- Damien Leone Sat, 04 Dec 2010 16:53:17 +0100 I don't know why... probably a mistake. - there's no lintian warning but I get an "info" level message: I: ncmpcpp: spelling-error-in-binary ./usr/bin/ncmpcpp informations information You could report that to upstream. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110120202732.ga7...@rivendell.home.ouaza.com
Re: RFS: dropbox
Hi, On Tue, 15 Feb 2011, Vincent Cheng wrote: > Dear mentors, > > I am looking for a sponsor for my package "dropbox". This package was > previously in Debian's repositories (its former maintainer was Ivan > Borzenkov ), but it was removed due to unresolved issues > with licensing. I have edited debian/copyright and fixed the issues > mentionned in a few bug reports, to the best of my abilities, and am willing > to fix any further issues identified in the package. Dropbox also provides integration with nautilus. Have you considered including this or packaging it separately? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110216071953.gb11...@rivendell.home.ouaza.com
Re: RFS: dropbox
On Thu, 17 Feb 2011, Vincent Cheng wrote: > Thank you for pointing that out; I'll make sure that is fixed in my next > upload to Debian mentors. Would it be all right if I simply included rsync > as one of Dropbox's dependencies, instead of including rsync binaries > directly in the source tarball? i.e. would I still have to provide the > source code that way? That's the correct fix indeed. You must then repackage the upstream tarball to drop the binary files whose sources are not provided. But as people pointed out, there's more than rsync in the tarball. And I don't know if dropbox is compatible with the current version of all those libraries. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217132521.ga6...@rivendell.home.ouaza.com
Re: RFS: Dropbox
On Sat, 19 Feb 2011, Vincent Cheng wrote: > I admit that I have no idea whether this will work, and if it is safe to > package Dropbox like this. However, since it seems that Dropbox is unlikely > to ever make it into the Debian archives if it still contained pre-compiled > libraries, this was the only alternative I had. It looks like this won't > work either, if Dropbox crashes and refuses to work properly. > > I'm now out of ideas; is there any other way of packaging Dropbox? Or should > I simply give up on ever seeing Dropbox in the repositories again? Fix the legal problems and have Dropbox provide the sources for the binaries provided by Dropbox. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110220125635.gc14...@rivendell.home.ouaza.com
Re: RFS: Dropbox
On Sun, 20 Feb 2011, Vincent Cheng wrote: > > Fix the legal problems and have Dropbox provide the sources for the > > binaries provided by Dropbox. > > Thanks; I didn't think of that. However, I still haven't received any reply > from upstream for my initial e-mail. If Dropbox replies to my e-mail, then > I'll try asking for the sources of those various libraries, but it looks > like upstream is unresponsive at the moment. If they do not react to request for sources for the GPL/LGPL components, you can always contact people who deal with gpl violations (FSF, gpl-violation.org). It's very effective usually. > If Dropbox provides the sources, would it simply be ok to include the > binaries along with all the source code, or would I have to set up a build > system where all the 50+ libraries in Dropbox have to be built from source > during the build process? The latter option would probably result in a long > and complicated build system, but I guess that might indeed be the only way > to package Dropbox. For a package in main, you have to build the binaries from the sources. For a package in non-free, it's less of a problem. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110221065607.ga28...@rivendell.home.ouaza.com
Re: Transition from oldpackagename to newpackagename
Hi, On Mon, 21 Feb 2011, Ben Finney wrote: > When making a new release of a source package that renames one of its > binary packages, at http://wiki.debian.org/Renaming_a_Package> it > is asserted “most package managers (including AFAIK apt) do not know to > replace the old with the new one”. > > Is that still true of APT? Or does APT now know that a new package > should be installed if it: > > Provides: oldname > Replaces: oldname (<< fooversion) > Conflicts: oldname (<< fooversion) > > In other words: is the dummy transitional binary package still needed to > transition an existing binary package to a new name Yes. > can we now expect package managers to figure it out from the metadata? No. And even if they did, it would still best practice to use a dummy package for a significant period of time. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110221074509.ge28...@rivendell.home.ouaza.com
Re: Conflicts or Breaks when there is no version number?
On Mon, 21 Feb 2011, Mathieu Trudel-Lapierre wrote: > "[Conflicts should be used] [...] in other cases where one must > prevent simultaneous installation of two packages for reasons that are > ongoing (not fixed in a later version of one of the packages)" > > I'm just trying to get a good understanding of this "special" case, > basically, whether it would be best here to keep a Conflicts line > despite the stricter requirements, or Breaks to simplify > installs/removal/upgrades and simply override the warning. Your case perfectly fits this description. Just like the mail servers conflict between themselves (via the mail-transport-agent virtual package), it's logical to allow only one of connman / network-manager. Breaks is meant for cases where two package usually coexist but due to an incompatible change in one of them, you want to force the upgrade of the other one to a version that has been updated to cope with the change. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110221200018.gb5...@rivendell.home.ouaza.com
Re: Struggling to remove old config files.
On Tue, 01 Mar 2011, Michael Lustfield wrote:
> I know the correct way to remove these files is with dpkg-maintscript-helper.
> I
> tried my hardest to use this correctly. I had a few incorrect uses pointed out
> to me that have since been corrected. However, I am still unable to remove
> these incorrect configuration files.
You should remove the files in the packages that own them. Thus
your dpkg-maintscript-helper calls should be in nginx{,-full,-light,-extras}
but not in nginx-common.
And the upgrade of those packages will then lead to the removal.
nginx-common is a new installation, and not an upgrade. And rm_conffile
is only activated on upgrade if you supply a version parameter like you
did.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302133616.gg20...@rivendell.home.ouaza.com
Re: Struggling to remove old config files.
Please keep the discussion on debian-mentors.
On Wed, 02 Mar 2011, Michael Lustfield wrote:
> The reason I put it in nginx-common was because nginx-{full,light,extras} are
> interchangeable packages. Someone could remove one and add another. An example
> would be the upgrade made them install nginx-full but they noticed and decided
> to try nginx-light.
And? Purging a package removes the configuration files. So that's ok.
If some configuration files are obsoleted in the process of upgrading foo
v1 to foo v2, then foo must remove those conffiles on upgrade. And it's
not the job of foo-common.
You're putting the configuration files in nginx-common precisely because
they are now shared between the various packages so that you always use
the same conffile whatever the current variant, right?
> They would have /etc/logrotate.d/nginx-{full,light}. If they upgrade
> nginx-light they would have one conf file removed, but not the other.
Right, but it's not a big deal. They would be removed by dpkg --purge
nginx-full.
If you really want to keep it in nginx-common, you have to supply
an empty version parameter so that it's always tried and not only during
upgrade.
dpkg-maintscript-helper rm_conffile /etc/logrotate.d/nginx-full "" nginx-full
-- "$@"
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302161856.gc5...@rivendell.home.ouaza.com
Re: dpkg-shlibdeps error
On Sun, 13 Mar 2011, Paul Wise wrote: > On Sun, Mar 13, 2011 at 5:38 AM, wrote: > > > I got this message while building a package : > > dpkg-shlibdeps: error: no dependency information found for > > /usr/lib/libgio-2.0.so.0 (used by foo). > > Sounds like the code is using gio but not linking against it. Please > fix the upstream build system to explicitly link foo against gio. Hum no. This message means that dpkg-shlipdes has found no associated shlibs/symbols files that provides the dependency for that library. There is a /var/lib/dpkg/info/libglib2.0-0.symbols in Debian. And dpkg-dev 1.16.0 is Ubuntu-only at this point... might be a multi-arch related bug. Fred, can you show me the output of those commands? $ dpkg-query --control-path libglib2.0-0 symbols $ ls -al /var/lib/dpkg/info/libglib2.0-0* $ dpkg -s libglib2.0-0 dpkg Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110313090443.gb26...@rivendell.home.ouaza.com
Re: RFS: libapache2-mod-qos (updated package)
Hello Sergey, On Sun, 13 Mar 2011, Sergey B Kirpichev wrote: > I am looking for a sponsor for the new version 9.54-1 > of my package "libapache2-mod-qos". Sorry for the delay, I had not forgotten you (otherwise I would have told you that I can't do the upload). I have uploaded the package but: > The package appears to be lintian clean. It's only apparent... $ debuild -S [...] Now running lintian... W: libapache2-mod-qos source: maintainer-script-lacks-debhelper-token debian/libapache2-mod-qos.postinst W: libapache2-mod-qos source: maintainer-script-lacks-debhelper-token debian/libapache2-mod-qos.prerm Finished running lintian. Strangely lintian does not show this warning when building the full package. I have reported this as a bug against lintian. > Note: this version set DM-Upload-Allowed debian/control field. I have dropped this, while I have advocated you for DM, I was hoping that you would get other recommandations besides mine as you have had several sponsors. I have seen too little on this package to be confident that you are able to manage it. I have asked you to switch to debhelper 7 tiny rules files for example and you responded that it might be complicated and have put it off too later. I don't think it is. When you have done 2-3 more of the TODO items that you have noted, I might be ok with adding the field. On Sun, 13 Mar 2011, Paul Wise wrote: > On Sun, Mar 13, 2011 at 5:53 AM, Sergey B Kirpichev > wrote: > > > Note: this version set DM-Upload-Allowed debian/control field. > > Only your previous sponsors can judge if this should be added. Also I > would think that 3 uploads would not be enough to judge anyones work. Indeed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110313095808.gc26...@rivendell.home.ouaza.com
Re: dpkg-shlibdeps error
Hi, On Sun, 13 Mar 2011, fre...@free.fr wrote: > > And dpkg-dev > > 1.16.0 is Ubuntu-only at this point... might be a multi-arch related bug. > Yes, Ubuntu natty in a pbuilder environment. So this is a bug specific to Ubuntu natty at this point and it will be fixed by the next dpkg upload to come in Ubuntu natty. In the mean time you could do this (as root): # mv /var/lib/dpkg/info/amd64/* /var/lib/dpkg/info/ # rmdir /var/lib/dpkg/info/amd64 # ln -sf . /var/lib/dpkg/info/amd64 Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110314221625.ga27...@rivendell.home.ouaza.com
Re: pbuilder and ${shlibs:Depends}
On Fri, 18 Mar 2011, Panayiotis Karabassis wrote: > I am still a little confused about this. Could you provide an > example/documentation to clarify this? From experience, I believe that > it WILL expand to LIBRARIES (not executables) that the program needs to > run, if said libraries are installed at build time. If not, what's its > purpose? It will expand to libraries which are listed in the NEEDED section of the ELF binaries present in your package. > > Add the missing dependencies manually AND use the variable. (At least > > this is what I do in all my packages. > > Thank you very much! This is really all I needed to know. Unfortunately this is wrong, at least for ELF binaries. Usually if you don't have all the dependencies that you expect, it's because they are optional and are disabled when they are not found during ./configure. Thus the correct solution is to add the required -dev packages in the Build-Depends so that ./configure finds the optional libraries that you want your program to use. Adding manual dependencies on C libraries is almost always wrong. > BTW, I'm not actually using dpkg-shlibdeps, but rather jh_depends. I > wanted to save some complication, since most developers are probably > more familiar with the former. You did not save some complication you just got wrong information due to this. It's unlikely that jh_depends works like dpkg-shlibdeps. I guess you need to have all the jars installed at build time and thus you want to add them to Build-Depends. But you should really ask for confirmation someone on debian-java@ or an experienced java packager (or maybe it's in jh_depends documentation). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110318194013.ga27...@rivendell.home.ouaza.com
Re: pbuilder and ${shlibs:Depends}
On Fri, 18 Mar 2011, Paul Gevers wrote:
> > Unfortunately this is wrong, at least for ELF binaries. Usually if you
> > don't have all the dependencies that you expect, it's because they are
> > optional and are disabled when they are not found during ./configure.
>
> Although I am just a simple DM, I still don't agree completely. Both my
> upstreams call binaries (not libraries) in their programs (via a shell
> or system call). As far as I can tell, that won't (and should not by the
> name) be picked up by the ${shlibs:Depends} variable. Especially for the
> shell call, I don't see an other way than providing it manually.
You're right on this one. But I think the question was about libraries
from the start.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110319080222.ga31...@rivendell.home.ouaza.com
Re: pbuilder and ${shlibs:Depends}
On Sat, 19 Mar 2011, Panayiotis Karabassis wrote: > So, to summarize: > > If: > a) /usr/bin/foo of package foo needs at RUN-TIME /usr/lib/libbar.so > b) /usr/lib/libbar.so is packaged under package libbar > > then I need to: > c) add package libbar-dev as a BUILD dependency of foo. > > And dh_shlibdeps will do its magic? How does this work exactly? Yes. man dpkg-shlibdeps to understand the details. > d) Does libbar-dev provide a DEBIAN/shlibs file that says that libbar.so > is packaged in package libbar? No, "libbar" provides the shlibs/symbols file but libbar-dev depends on libbar so you get it implicitely. And you also need the /usr/include files in libbar-dev... > Is the above correct? Almost. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110319080436.gb31...@rivendell.home.ouaza.com
Re: Packaging Arbitrary Files
Hi, On Tue, 29 Mar 2011, Russ Allbery wrote: > 1. dpkg-divert the configuration file before replacing it with yours. >This sort of works and sort of doesn't. dpkg doesn't deal well with >diverted configuration files in all cases, and you'll get odd >problems. Whether those odd problems will be significant or not for >you is hard to say. > 3. Have your package declare that it Replaces the package that ships the >configuration file. This sort of works, but it's probably a bad idea, >since upgrading the original Debian package will probably overwrite >your package's files right back, or result in other weird changes. For both of these points, dpkg should do the right thing nowadays. If it doesn't you're welcome to file a bug report. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330060509.gd20...@rivendell.home.ouaza.com
Re: dpkg-buildpackage -A vs make -f ./debian/rules build-indep
On Mon, 04 Apr 2011, Mathieu Malaterre wrote: > Dear all, > > I am trying to understand why dpkg-buildpackage -A is not simply > calling make -f ./debian/rules build-indep. I tried turning > DH_VERBOSE=1 but I do not see which rules imply runing the build-arch > while I specifically tell dpkg-buildpackage to only run build-indep. This is a long standing limitation of both the policy and dpkg-buildpackage. See #229357 for instance and also some report against debian-policy. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404121630.ge25...@rivendell.home.ouaza.com
Re: Bizzar error with dpkg-buildpackages
On Tue, 05 Apr 2011, Michelle Konzack wrote: > Hello Mentors, > > I am not compiling the package the first time, but today I got an error > on Squeeze which could be lead to the yesterdays "upgrade": No, not related. > Ehm, on the top, dpkg-deb say "signfile xmem_1.20-29+b1.dsc" and then at > dpkg-genchanges I get "../xmem_1.20-29.dsc can't be read". I compiled > the last two days 16 Packages and it was working and now not more. > > Any suggestions what it can be that the "+b1" is cut off? Because "+b1" means bin-nmu 1 and is never part of the source version. That's policy. Don't put "+bX" at the end of your version and you'll be fine. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405092244.gc10...@rivendell.home.ouaza.com
Re: Cannot push changes to git repo
On Tue, 24 May 2011, Steffen Möller wrote: > On 05/24/2011 10:43 AM, Dimitrios Eftaxiopoulos wrote: > > $ssh eftaxiop-gu...@git.debian.org > > > > I get the same rejection. > The same here. The public key is rejected and no password asked (run > with -v). > I presume the folks are aware of it all. Verify if the SSH keys are still correct in https://alioth.debian.org/account/editsshkeys.php If yes, then report the problem to alioth admins because SSH access is supposed to work. But password-based logins have been disabled. Debian developers do not have to add their keys if they have it already recorded in db.debian.org, they are already auto-installed by another mean. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524093331.ga1...@rivendell.home.ouaza.com
Bug#628285: RFP: xul-ext-pencil -- GUI prototyping and diagram tool
Package: wnpp Severity: wishlist * Package name: xul-ext-pencil Version : 1.2 Upstream Author : Nguyen Tien Dung * URL : http://pencil.evolus.vn * License : GPL2+ Programming Lang: Javascript / Xulrunner app Description : The Sketching and GUI Prototyping addon for Firefox/Iceweasel The Pencil Project's unique mission is to build a free and opensource tool for making diagrams and GUI prototyping that everyone can use. Top features: Built-in stencils for diagraming and prototyping Multi-page document with background page Inter-page linkings! On-screen text editing with rich-text supports Exporting to HTML, PNG, Openoffice.org document, Word document and PDF. Undo/redo supports Installing user-defined stencils and templates Standard drawing operations: aligning, z-ordering, scaling, rotating... Cross-platforms Adding external objects Personal Collection Clipart Browser Object snapping Sketchy Stencil And much more... I discovered this software a few weeks ago and I would like to see it packaged for Debian (but I don't want to do it myself). It should probably be maintained under the umbrella of the pkg-mozext team: http://wiki.debian.org/Teams/DebianMozExtTeam Unfortunately the current version is not compatible with Firefox 4 yet. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110528134820.ga12...@rivendell.home.ouaza.com
Re: what happens if DM annual ping is late ? removed from keyring ?
Hi, On Mon, 30 May 2011, Jérémy Lal wrote: > Hi, > i reported my DM annual ping at the anniversary date, > and now i can't upload : > > Reject Reasons: > kapo...@melix.org is not in Maintainer or Uploaders of source package redmine > > is this expected until the bug report has been processed, > or am i missing something ? I feel a bit worried about that :) It's unrelated. It's likely a problem in the dak setup. The error message doesn't imply that you're not in the DM keyring but that you're not listed for the given package (which you are). Get in touch with ftpmasters to solve the issue. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531060553.gb5...@rivendell.home.ouaza.com
Re: Git and tarballs
On Wed, 06 Jul 2011, Wolodja Wentland wrote: > Tarball only > > > Branches > > > NameLocal/RemoteMerges From Tracks > - > master local n/a alioth/master > upstreamlocal n/a alioth/upstream > pristine-tarlocal n/a alioth/pristine-tar > alioth/master remote n/a > alioth/upstream remote n/a > altoth/pristine-tar remote n/a > > Workflow > > > Tarballs are downloaded from upstream and merged with git-import-orig, > orig tarballs are constructed from upstream + pristine-tar. > > Questions > - > > * Is pristine-tar *really* needed here as it will basically say "No change > from > upstream"? > I have to confess that I don't quite see the merit of pristine-tar > when generating tarballs as those should be exactly the same tarball > as produced by "git archive TAG. Or am I missing something here? You are missing the fact that the two tarballs will be different because: 1/ the files in the archive might not be in the same order 2/ the "gzip" compression might be different (it embeds a timestamp and the name of the original file by default) The goal of pristine-tar is to regenerate exactly the same tarball (i.e. same MD5/SHA1/etc. checksum). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110708063110.gk8...@rivendell.home.ouaza.com
Re: Nitpicking: you are doing it wrong
On Sat, 09 Jul 2011, Thomas Goirand wrote: > My point to give arguments about not using dh was *not* to start a troll > thread about what is best practices. It was simply to tell that there > are some arguments for and against using dh, and as a consequence, I > found very bad to write in this list that not using dh was a bad idea. Not using dh for a new package is a bad idea IMO. Sure enough, you can do the packaging once without dh to force you to learn the commands and what's going on. That's fine. But then when you're doing the packaging that you want to submit to Debian, it's best to use dh because the package will be more maintainable on the long run (for all the good reasons that have already been given). I don't share at all the 2 arguments that you listed against dh: - performance is not a real problem, the few seconds of build time are neglible even for small package, 5 seconds more in a build doesn't change much compared to the time you have invested in creating the package - readability, I find the override very good to point out what's special in the package (you would not notice in a normal debhelper package that a dh_foo call has been moved in the list) Of course, it's not a requirement at the debian level. But that's not a good reason to not recommend it to newcomers. They don't have the required experience to know what's best for them. Thus we should point them towards something largely accepted and recommended. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110709190517.gd30...@rivendell.home.ouaza.com
Re: Adding symbols files to the tango package.
On Mon, 01 Aug 2011, Michael Tautschnig wrote:
> Indeed symbol ordering may vary, but also there is no reason for
> dpkg-gensymbols
> to guarantee a particular ordering.
Well, dpkg-gensymbols does sort the symbols files. Precisely so that
diff are meaningful. Otherwise they would be useless.
Code extract:
foreach my $sym (sort { $a->get_symboltempl() cmp
$b->get_symboltempl() } @symbols) {
What this means is that the symbols files provided by the package is not
properly sorted...
That said the generated diff should not always be applied as is. In many
cases if you have used tags and patterns in your symbols files, adding a
new symbol requires some "post-processing" to make it fit with the way the
symbols file is managed.
For example deactivating a symbol on a specific architecture requires fiddling
with an arch tag rather than removing the symbol...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110803062605.gc28...@rivendell.home.ouaza.com
Re: RFS: smarty
Hi, thanks for your interest in smarty. On Mon, 01 Aug 2011, Wojciech Szaranski wrote: > The package appears to be lintian clean. > > The upload would fix these bugs: 514305 Have you read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514305#10 ? Because: 1/ you have not taken care of the case where other packages install files in /usr/share/php/smarty/libs/plugins (i.e. no preinst, no conflicts, nothing for this) $ apt-file search /usr/share/php/smarty/libs | cut -d: -f1 | uniq collabtive smarty smarty-acl-render smarty-gettext smarty-validate 2/ you have not informed me 3/ you have not contacted any other maintainer of a reverse-dependency asking them to test with your updated package (and warning them that a new upstream version will land shortly in Debian) (but before doing so, let's fix this package) $ apt-cache showpkg smarty Reverse Depends: piwigo,smarty 2.6.26 moodle,smarty smarty-acl-render,smarty gosa,smarty smbind,smarty smarty-validate,smarty smarty-gettext,smarty slbackup-php,smarty serendipity,smarty piwigo,smarty 2.6.26 phpgacl,smarty 2.6.9 ojs,smarty moodle,smarty kolab-webadmin,smarty gallery2,smarty 2.6.26 collabtive,smarty Maitaining a library requires more care than the usual package, please pay attention to everything. > My motivation for maintaining this package is: I would like to share > packages that I'm using :) Great, but you should make it work for everybody and not only you. :-) A few remarks: - you should not package it as a Debian native package but as "3.0 (quilt)" mkdir debian/source echo "3.0 (quilt)" > debian/source/format - you should indicate in the changelog which security issues are fixed by this upload by incorporating all the corresponding CVE numbers http://security-tracker.debian.org/tracker/source-package/smarty - you should update it to the latest Standards-Version (verify that it follows the latest policy with /usr/share/doc/debian-policy/upgrading-checklist.txt.gz) - the package does not even build currently because "make" invokes "make install" as that's the only target and "debian/rules build" does not have the required root rights There's lots of work left as you can see. You should really also check your package with lintian on Debian unstable, there are lots of issues: W: smarty source: native-package-with-dash-version I: smarty source: missing-debian-source-format W: smarty source: out-of-date-standards-version 3.8.4 (current is 3.9.2) W: smarty: wrong-name-for-upstream-changelog usr/share/doc/smarty/change_log.txt.gz W: smarty: debian-changelog-line-too-long line 2 E: smarty: helper-templates-in-copyright W: smarty: symlink-is-self-recursive usr/share/php/smarty/libs . I: smarty: package-contains-empty-directory usr/share/doc/smarty/demo/cache/ I: smarty: package-contains-empty-directory usr/share/doc/smarty/demo/templates_c/ Obviously "W: smarty: symlink-is-self-recursive usr/share/php/smarty/libs ." can't be fixed, you have to override it and document the reason for this override. Please CC me for a secound review once you have fixed everything reported here. Feel free to ask questions as well if you don't understand something. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803065527.gd28...@rivendell.home.ouaza.com
Re: RFS: smarty
On Wed, 03 Aug 2011, Raphael Hertzog wrote: > Because: > 1/ you have not taken care of the case where other packages install >files in /usr/share/php/smarty/libs/plugins (i.e. no preinst, no >conflicts, nothing for this) Just to clarify, you should add versioned conflicts on all those packages so that they are upgraded/removed before smarty is upgraded. Of course the other packages have to provide new versions with the files moved for this to work. Thus you have to coordinate with those maintainers. The postinst should have some code to drop the directory /usr/share/php/smarty/libs and replace it with a symlink because the simple upgrade will not replace it properly (dpkg does not replace dir by symlinks and vice-versa, per policy). On a unrelated note, it would be a good idea to maintain this package in a public VCS repository on collab-maint (my preference goes to git): http://wiki.debian.org/Alioth/PackagingProject Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803070518.gf28...@rivendell.home.ouaza.com
Re: RFS: smarty
Hi, On Wed, 03 Aug 2011, Thierry Randrianiriana wrote: > On Mon, Aug 1, 2011 at 3:23 PM, Wojciech Szaranski wrote: > > * Package name : smarty > > Version : 3.0.8-5 > > There is a smarty3 package with the same version > http://packages.debian.org/sid/smarty3 . And you are the maintainer of it... can you elaborate why you packaged it under a new package name? We certainly don't want 2 versions of this package in the long term in Debian. Please ensure we have some sort of upgrade plans to get back to 1 version only. In particular given the number of security issues that have affected it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803093546.gj28...@rivendell.home.ouaza.com
Re: Adding symbols files to the tango package.
On Wed, 03 Aug 2011, Picca Frédéric-Emmanuel wrote: > What do your mean exactly by sorted ? > > sorted using the 'sort' program ? > sorted like the un-mangled symbols ? IIRC it's sorted alphabetically on the string that appears in the symbols file (i.e. un-mangeld symbol in your case). The tags are ignored for the sort. > It means also that if I use #include it is no more possible to use the patch > right ? Right. It's also one of the reasons why we prefer using arch tags instead of arch-specific files with includes. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804060244.gg1...@rivendell.home.ouaza.com
Re: debconf scripts
Hello, On Mon, 03 Oct 2011, kuLa wrote: > On 03/10/11 12:56, Mohsen Pahlevanzadeh wrote: > > Suppose i download a *.deb from internet or packages.debian.org, How i > > can find out it has prerm, postrm, postinst...preinst and so on? > > which command? Can i find out? > > just unpack it and voila :-) > > ar -x package.deb && tar xzf control.tar.gz It would be more useful to direct users to the correct interface for this: $ dpkg -I package.deb "man dpkg" and "man dpkg-deb" for the details. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003124104.ge27...@rivendell.home.ouaza.com
Re: Fwd: dpkg-source: error: expected [ +-] at start of line
On Sat, 08 Oct 2011, Rodolfo kix Garcia wrote: > But, IMHO, this is a bug. Because I can patch using quilt but not > with dpkg-buildpackage. Same code, different behavior. It's not a bug. This patch has probably been badly hand-edited or something similar. diff would never generate such a patch. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111008073904.gd5...@rivendell.home.ouaza.com
Re: Remove self from Alioth
Hello, On Fri, 14 Oct 2011, Jason Heeris wrote: > I have an account on Alioth, but I'm no longer using or contributing to > Debian. Can I remove or deactivate my account, or should I just abandon it? You should file a support request to get it removed, see http://wiki.debian.org/Alioth/FAQ#How_can_I_remove_my_old_-guest_account_.3F_an_unused_project_.3F Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111014060003.gh15...@rivendell.home.ouaza.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi, On Tue, 17 Jan 2012, Ansgar Burchardt wrote: > We plan to ask for the creation of a new pseudo-package > debian-mentors or mentors.debian.org [3] (contact: > debian-mentors@lists.debian.org) in Debian's bug tracking system (the > name is still subject to change). A workflow for handling sponsoring > requests is proposed below. It is based on an earlier discussion on the > debian-mentors list[1]. The proposal looks great. And I like that it will allow us to know more, and in an automated way, about the status of a current sponsorship request. That way the PTS can provide more precise information instead of just telling that a package is available on mentors.debian.net. To better fit the naming of pseudo-packages, we ought to pick mentors.debian.org but it would be weird if that DNS entry did not exist. Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120118074034.gj12...@rivendell.home.ouaza.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Wed, 18 Jan 2012, Adam Borowski wrote: > > Anyway, I don't think closing RFS bugs manually would be big hassle > > to sponsors. > > An additional manual step that takes time, is error-prone and brings nothing > new: if the upload fails somehow, the sponsor will be the first to get > notified. Personally, I always notify the sponsoree when I proceed with the upload. It would be relatively trivial to add the CC to nnn-done at this point. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119083953.ge7...@rivendell.home.ouaza.com
Re: Package version numbers
On Wed, 16 Jan 2013, Christian PERRIER wrote: > Quoting Jakub Wilk (jw...@debian.org): > > I would paint the bikeshed the following color: > > 0.8.51+dfsg1-0.1 > > Isn't that missing the fact that this is a t-p-u upload, which is > indeed the start of a "wheezy" branch? > > So something we were naming "+wheezy" in the past and which we > now name "+deb70u1". It's not really relevant because sid has already diverged and has a higher (upstream) version. So 0.8.51+dfsg1-0.1 is acceptable IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130116084941.gd18...@x230-buxy.home.ouaza.com
Re: Work-needing packages report for Jan 25, 2013
Hi, On Fri, 25 Jan 2013, w...@debian.org wrote: > The following packages have been given up for adoption: > >salt (#698772), offered yesterday > Description: remote manager to administer servers > Installations reported by Popcon: 90 I just wanted to point out that this package is — unlike most orphaned package on this list — a relatively recent software that is actively maintained upstream and is likely to have a significant user base while it matures (I use it). This might be interesting for some of you who are looking for something to package (even in co-maintenance). http://saltstack.org Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130125071521.ga1...@x230-buxy.home.ouaza.com
Re: Trying to use dh_linktree to replace jquery.js but failed
Hi, On Fri, 10 May 2013, Andreas Tille wrote: > $ cat debian/libgtkdatabox-0.9.2-0-doc.linktrees > replace usr/share/javascript/jquery/jquery.js > usr/share/doc/libgtkdatabox-0.9.2-0-doc/html/jquery.js > $ grep -A1 dh-linktree debian/control >dh-linktree, >libjs-jquery > > does not seem to do the magic I want it to do. Any hints? You need to call dh_linktree at some point, probably by using "dh --with linktree"... Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510151619.ga...@x230-buxy.home.ouaza.com
Re: lintian: no-upstream-changelog + non-standard changelog
Hi, On Thu, 16 May 2013, Felix Natter wrote: > Eric (the previous packager) installed this file as > /usr/share/doc/freeplane/history_en.txt.gz, which seems ok. But how > should I deal with the no-upstream-changelog lintian warning? Pass "history_en.txt" to dh_installchangelogs and let it do its work: > - install this file only as /usr/share/doc/freeplane/changelog.gz It will do this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130517082813.gg2...@x230-buxy.home.ouaza.com
Re: réduire la taille d'un paquet source et ajouter des paramètres spécifiques dans le fichier control
[Indicating that -mentors is an english list] Bonjour Zoubeïda, debian-mentors est une liste anglophone. Il faut donc poser vos questions en anglais. Autrement vous pouvez essayer d'utilisez debian-devel-french: http://lists.debian.org/debian-devel-french/ Je réponds en anglais à la suite: On Mon, 19 Aug 2013, Zoubeïda Zarkouna wrote: > 1) j'aimerai réduire la taille de mon paquet source généré! est-ce qu'il y > a un moyen afin d'ignorer des dossier lors de la création d'un paquet > source? > je viens de tester : export DH_ALWAYS_EXCLUDE=.bzr-builddeb:logs > dans le fichier rules mais ça ne marche pas! je n'ai pu exclure que le > dossier .bzr a travers l'option "-I" du debuild. It's effectively the -I option that you should use if your package is a native one. You can make the -I option permanent by creating debian/source/options and putting this: tar-ignore = .bzr-builddeb:logs tar-ignore = .bzr See "man dpkg-source" for details. > 2) est-il possible d'ajouter des attributs spécifiques au niveau de mon > fichier control: > j'ai essayé avec la commande : > > dh_gencontrol -- -D'bzr_revid'='123' > ---> ça ne me rajoute rien dans le fichier control et la susbtitution non > plus! bzr_revid is not a valid field name. Try with "-DBzr-Revid=123". > dh_gencontrol -- -D'Maintainer'='ZARKOUNA ' This is usually put in debian/control and not set via this option. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130820072839.gh14...@x230-buxy.home.ouaza.com
Help needed to maintain wordpress
[ Bcc debian-devel to make the offer both to new maintainers and experienced ones ] Hello, I would like to find someone willing to take over the maintenance of wordpress in Debian (the most popular software to run a blog). The package is in a relatively good shape but it needs active maintenance to keep up with new upstream releases and security updates. One of the immediate challenge that I won't have the time to tackle is that the Debian package has been providing translations in wordpress-l10n for a long time already, but upstream just rolled out a new "language pack" mechanism and we probably need to adapt debian/get-upstream-i18n to use this new mechanism. Some PHP programming skills are required for this task. I have also left a debian/TODO with some more changes that we should implement. I will gladly sponsor uploads for non-DD. Cheers, PS: Giuseppe Iuculano is marked as the main maintainer but at least for wordpress he's MIA. Giuseppe, do you intend to work again on wordpress or shall you be removed from the maintainer field ? PPS: I have just uploaded wordpress 3.7.1 but can't push to git.debian.org currently since it's down. I have pushed a copy to https://github.com/rhertzog/wordpress -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131114103654.ga19...@x230-buxy.home.ouaza.com
Re: Help needed to maintain wordpress
Hello Nicolas & Pablo, On Thu, 14 Nov 2013, Nicolas wrote: > I can try to help. I'm a php developper and and I help the maintainer of > dotclear package (another great project to make a blog !!). On Thu, 14 Nov 2013, pablo vazquez wrote: > I'm starting with debian but i have strong background with wordpress and > PHP. I would like to help with this. Thank you both for your help offers. The first step is to subscribe to the package on the Package Tracking System: http://packages.qa.debian.org/wordpress Use the advanced subscription form and make sure to enable the "cvs" keyword so that you get notifications of commits. > > I have also left a debian/TODO with some more changes that we should > > implement. > > I see the TODO file and i can handle it. Great, feel free to send me patches or to point me to a Git branch that can be merged. Obviously, there's also the list of open bugs that can benefit from some attention. If you have questions about anything related to wordpress maintenance, just ask. Next time there's a release, I expect that one of you will prepare it in Git so that I can just sponsor it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131114125628.gb2...@x230-buxy.home.ouaza.com
Re: Help needed to maintain wordpress
Hi, On Thu, 14 Nov 2013, Ean Schuessler wrote: > I've been looking to get myself back involved with Debian and have been > looking for something useful to work on. Our day to day paying work > requires that we work with Wordpress and we have an interest in trying > to automate installs (which we are currently doing with Ansible). I > would be willing to take on the package. If you can hang around for a > bit of a "trial period" you could review my work and ensure that I'm > living up to my responsibilities. Sure, I'm definitely available to review your work. Two other persons expressed interest in the package, see http://lists.debian.org/debian-mentors/2013/11/msg00153.html so you should really coordinate with them as well. But they're rather new contributors and they could need some help/direction from you and me. > ps. I wasn't sure if you and Giuseppe are on the mentors list so I have > copied both of you. I prefer being cced even though I'm on the list. Thanks. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131114160423.gc12...@x230-buxy.home.ouaza.com
Re: No relro when building from inside a Git package ?
Hi, On Fri, 22 Nov 2013, Andreas Tille wrote: > $ gbp-clone ssh://git.debian.org/git/debian-med/htslib.git > $ cd htslib > (debian/unstable) $ git branch > * debian/unstable > develop > pristine-tar > (debian/unstable) $ git-buildpackage > (debian/unstable) $ lintian -I --pedantic > ../build-area/htslib_0.2.0~rc4-1_amd64.changes The mere fact that the generated files are in ../build-area/ means that you're using --git-export-dir (via ~/.gbp.conf) and thus you are building in a directory that doesn't have the .git dir. It's an export (with git archive) that is unpacked in ../build-area// that you use as build directory. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131122081044.ga8...@x230-buxy.home.ouaza.com
Re: dh: different dh option for -indep
Hi, On Mon, 30 Dec 2013, Andreas Metzler wrote: > Assuming foo-doc is arch independent and therefore not built on -B this > should work: > > MYDHMODS := $(shell if dh_listpackages | grep -q foo-doc ; \ > then echo "--with autoreconf,sphinxdoc" ; \ > else echo "--with autoreconf" ; fi) > > %: > dh $@ $(MYDHMODS) Nice trick! Still, this is a wrong optimization IMO. This complexifies the packaging for no important gain. It could be different if the package was one of those required to bootstrap a new architecture but for a random package, it's just easier and more maintainable to keep the sphinxdoc build-dep in Build-Depends. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013123602.ga15...@x230-buxy.home.ouaza.com
Re: How to selectively silence git-multimail messages ?
On Fri, 24 Jan 2014, Russ Allbery wrote: > Charles Plessy writes: > > > Sometimes, I can guess in advance that a push will generate a flood of > > emails that will not be very relevant at best and annoying at worse on > > my packaging team's mailing list. For instance, merges from upstream's > > master branch, with hundreds of commits that do not change the contents > > of the debian directory. Sometimes, to avoid them, I log on Alioth and > > disable temporarly the commit hook. > > > Would anybody be able to improve the system so that, when pushing with the > > --quiet option, the individual emails for each commits will be skipped ? > > I've been wondering about this too. Something to send out only a summary > mail message if a given push results in, say, more than 20 commits would > be very nice. > > The last time I pushed the upstream merge for OpenAFS, I think it sent > about 200 mail messages with all the upstream changes since the previous > release. There's no good answer unfortunately. There's this ticket requesting the possibility to filter commit notices per branch: https://github.com/mhagger/git-multimail/pull/15 But it hasn't seen any recent progress. And somehow I fear it would work correctly only if you take care to push the upstream branch first in a separate push. The possibility to limit the number of commit notices also looks like a good idea, I filed it here: https://github.com/mhagger/git-multimail/issues/41 Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140126102035.gb31...@x230-buxy.home.ouaza.com
Re: How to selectively silence git-multimail messages ?
On Sun, 26 Jan 2014, Raphael Hertzog wrote: > The possibility to limit the number of commit notices also looks like a > good idea, I filed it here: > https://github.com/mhagger/git-multimail/issues/41 Apparently that feature already exists, I just overlooked it. In the Alioth git repository, just call: $ git config multimailhook.maxCommitEmails 20 The default value is very large (500). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140130102105.ga2...@x230-buxy.home.ouaza.com
Bug#744253: RFS: ledgersmb/1.3.39-1 [RC]
On Wed, 23 Apr 2014, RJ Clay wrote: > >Raphael Hertzog is active according to MIA, so he's probably just a > >bit too busy right now to handle RFS requests. > >Wouldn't surprise me at all.. Indeed, I have been busy with a move to a new house. Sorry for my lack of response. > >I'd feel a lot more comfortable if your original sponsor could review > >this (the maintainer scripts in particular due to their complexity), > Wouldn't mind it myself, although he did note back in January that his > "interest in LedgerSMB" might "fade" due to switching to a different > program. OTOH, he also indicated he'd respond to questions, so may just be > busy. Right, I completed my move to tryton and I'm now also sponsoring the tryton maintainer in Debian... so I would certainly be happy if Vincent was willing to sponsor you instead. Otherwise I'll try to have a look at it later. Possibly by the end of the week. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140428133353.gi30...@x230-buxy.home.ouaza.com
Re: packaged perl module
Le Fri, Aug 22, 2003 at 10:47:48AM -0700, Josh Lauricha écrivait: > I'm renaming the libtext-csv-perl module to libtext-csv-xs-perl (it > provides Text::CSV_XS not Text::CSV). > > It is lintian clean, however linda complains that an arch specific file > end up in /usr/share/perl5 > > If I have it in /usr/lib/perl5 lintian complains... > > What's the correct thing to do here? the perl policy is very vague. The correct thing to do is to let perl decide where to put it ... lintian's warning is wrong and you should ignore it. Alternatively you could try to convince Josip Rodin to remove that warning since it confuses so many people, but I already tried and failed. > Since it conflicts with libtext-csv-perl should I Provide & Conflict it? Sure and replaces also (just to avoid troubles). Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
