Re: What to do if the original tarball contains a debian subdirectory
2009/1/28 Al Nikolov : Luca Niccoli wrote: The original tarball already contains a debian subdirectory (which needs some corrections anyway), how should I deal with that? If I dh_make straight after unpacking the tarball, dh_make won't modify the debian subdirectory; but I wonder if removing it beforehand will tamper the orig.tar.gz It's nothing wrong to make changes in ustream's /debian directory wich will be represented in diff I have a similar question. Upstream has file ./debian/files in their tarball. Lintian complained about that file so I've deleted it. But during build in pbuilder it gets added back from the orig tarball. How to handle this? -- With best regards Ледков Дмитрий Юрьевич signature.asc Description: OpenPGP digital signature
What to do if the original tarball contains a debian subdirectory
2009/1/29 Eduardo M KALINOWSKI : I'd say it depends on what you are doing. If you are building on the work already there, keep the changelog. But if you are ignoring upstream's debian/ directory and starting your packaging from scratch, you can drop it. By keep the changelog you mean add my own new changelog entry at the top of the file as if it was the debian changelog? ps. To: Eduardo - sorry for sending this message twice -- With best regards Ледков Дмитрий Юрьевич -- With best regards Ледков Дмитрий Юрьевич -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.2) iEYEARECAAYFAkmCJ2cACgkQh/npNECdyEZ6ugCfS4rdMlUFVmD3BbTjkIE+Jh/0 nmwAn1VXwCQAXdAst4BwdVWb+l6hjTPy =qWCB -END PGP SIGNATURE- signature.asc Description: OpenPGP digital signature
Re: [Python-apps-team] RFS: cgmail (adopted)
2009/2/16 Sandro Tosi : > > you'd be welcome to so do :) You can find some documentation at [1] > [2] [3], and feel free to ask d-pyt...@l.d.o for clarification or, if > you hang around irc, we're on #debian-python at irc.debian.org. > > [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam > [2] http://python-apps.alioth.debian.org/policy.html > [3] http://wiki.debian.org/PAPT_Howto > Thanks for the links. Inject didn't work so I did the manual injection. Looks good to me =D * Updated Maintainers field to PAPT * Set myself in Uploaders * Update VCS-* fields to point to svn * Rebuild from svn and uploaded to mentors I again kindly request to sponsor this upload for me. I am looking for a sponsor for the new version 0.5-1 of my package "cgmail". It builds these binary packages: cgmail - A new shiny mail checker for the GNOME desktop The package appears to be lintian clean. The upload would fix these bugs: 461447, 515539 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cgmail - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cgmail/cgmail_0.5-1.dsc -- With best regards Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dch multi-maintainer mode
Dear all Is it still allowed as per 3.8.1 policy to use multi maintainer style changelogs? (Asking because of the explicit statement of one type of changlelog and new upgrade to must) Eg. foobar (1.5.11-1) unstable; urgency=low [ Joe Plow Mber ] * New upstream release [ Vasja Pupkin ] * debian/patches - added patch descriptions -- Vasja Pupkin Sat, 04 Apr 2009 23:09:16 -0700 -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dch multi-maintainer mode
Thanks a lot everyone =D -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич
Re: RFS: gnome-inm-forecast (updated package)
2009/4/28 Ryan Niebur > > Hi, > > I am about to leave again, so haven't looked much more, but... > > On Tue, Apr 28, 2009 at 02:03:58AM +0200, Gustavo Iñiguez Goya wrote: > > > > By the technical side, an important bug has been fixed, which caused to > > not work on GNOME 2.26: > > https://bugs.launchpad.net/ubuntu/+source/gnome-inm-forecast/+bug/351398 > > > > why have you closed this bug in Ubuntu? afaict, it has not yet been > fixed in Ubuntu itself. > > you should reopen that bug, and make your changelog look like this: > > * New upstream release. > - initialize GNOME VFS, fixing this under GNOME 2.26 (LP: #351398) > > then it will be automatically closed when this package gets uploaded. > > Thanks, > Ryan > Is it ok to include LP: # bug numbers in changelog in packages aimed at debian? Or is the above package special? -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: mpview
2009/5/2 Magnus Holmgren : > On torsdagen den 26 mars 2009, Michal Čihař wrote: >> Dne Thu, 26 Mar 2009 15:21:29 +0100 >> >> Adam Ziaja napsal(a): >> > The package appears to be lintian clean. >> >> It does not: >> >> I: mpview source: debian-watch-file-is-missing >> W: mpview source: dh-clean-k-is-deprecated >> W: mpview source: out-of-date-standards-version 3.7.3 (current is 3.8.1) > > Hang on a second. When does mentors.d.n put "The package appears to be lintian > clean" in the RFS template? When lintian reports no errors or warnings, or as > soon as there are no errors? > I think it's not running lintian at all, that text is just boilerplate which assumes mentees did run lintian. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to create quilt-based source packages using debuild
2009/5/3 Noel David Torres Taño : > On Sunday 03 May 2009 08:15:42 Benjamin Mesing wrote: >> Hi, >> >> I am having trouble understanding how to build a quilt based >> source-package. My packaging is based on quilt, but when running >> debuild, debuild creates a traditional style source package. >> I've tried to add "Format: 3.0 (quilt)" to the control file and a Format >> 3 source package is correctly created (i.e. an orig.tar.gz and a >> Ben >> > > I do not know exactly about your problem (I tink I do nos use the same tools, > but do not remember just now), but I have a "3.0 (quilt)" package too, and I > must tell you that the Debian archive is not (yet) able to have it, so your > mentor will not be able to upload it. > > Best wishes > > Noel Torres > er Envite > I have similar but different issue with 3.0 (quilt). My current package is using quilt for patches. When I convert it to quilt 3.0 the debian-diff patch has the usuall patches as well. So my patches are applied and then removed by debian-diff patch resulting in FTBFS. Are there any guidelines on how to convert package to 3.0 (quilt) which already uses patch system? Cause my brain failed. assuming that dpkg does everything as designed. (Package sword in experimental for example from my team packages) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: include desktop file and icon
2009/5/9 Grammostola Rosea : > Neil Williams wrote: >> >> On Sat, 09 May 2009 21:11:25 +0200 >> Grammostola Rosea wrote: >> >> >>>> >>>> After you build the package, check the contents of debian/tmp >>>> >>>> Use the matching paths in your own files. >>>> >>>> >>> >>> I can't find an debian/tmp folder... >>> >>> \r >>> >> >> You've probably only got a single package, so check the contents of >> debian/$package >> >> > > Doesn't have that either.. > A quick tutorial about debian packaging "states". When you build your package everything that needs to be compiled gets compiled. Then everything is installed into a temporary directory inside debian/ then various dh_ commands are run to change/make the temporary directories fit for actual binary .deb. At the the end metadata, maintainer scripts and those temp directories are compressed into an archive with name ending in deb. To get better understanding let's do this: 1) Change into the directory of your package, eg. cd foo-1.0/ 2) Run this command debuild binary 3) Now go into debian/ and look what you have in there. A good way to see what's there is to run this: du -a This should show all the files in all subdirectrories. One particular directory you want to look at is the one named after your package (hope you are still following, I'm talking about foo-1.0/debian/foo). It has all the files that will end up in the final deb. Sometimes (if you are building more than one package) you will have 3 folders e.g.: tmp/ foo/ foo-data/ Sometimes you will notice that upstream compilation doesn't install everything you want. In that case you create the debian/$foo.install files. Case 1 Single package (you are only creating ONE deb) Step 1) create debian/install Step 2) For each missing file/directory write one line: source destination-dir Where source is path relative the toplevel source directory (foo-1.0), and destination-dir is where you want the files to end up when your package is installed on the system eg. (usr/share/lib/) Case 2 Multiple deb package (youare creating MORE THAN ONE deb) Step 1) create debian/$(package).install eg. if you want to install something additionally into a package called supercow-data you create a file debian/supercow-data.intall Step 2) Same as in case 1. > I have package.install > > with: > > debian/tmp/usr/share/applications/* usr/share/applications/ Most likely you want to simply write upstream/location/of/desktop/files usr/share/applications And rename "package.install" into simply "install". "upstream/location/of/desktop/files" is the path to the .desktop file/files in the tarball eg. one of my upstreams has desktop files in vitables-2.0/unixapp/vitables.desktop so in my debian/install I have this line: unixapp/vitables.desktop usr/share/applications Hope this helps. please take a little bit of time and play around with it to understand which paths you need to be using when. It's something I had to spend a little while to get the hang of. If you have anyquestions please ask. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libbash
2009/5/11 Boyd Stephen Smith Jr. : > In <20090510233757.gb6...@ime.usp.br>, Rogério Brito wrote: >>On May 10 2009, Patrick Matthäi wrote: >>> But linda, lintian, dpkg and some other tools are purely developed for >>> debian, and make no sense being released in another distribution. >>> quote --> >> >>Those packages are used by distributions like Ubuntu, for instance, and >>the wording of that part may leave newer maintainers puzzled. > > Use in other Debian-based systems is not always reason enough to make > something non-native. (Use in a non-Debian-based OS generally is.) dpkg and friends version numbers in Ubuntu are released with "native ubuntu" version numbers. So really anyone who is using dpkg in their distribution is more correctly maintains his/her own native branch which is similar to debian one. I don't think debian wants to become universal upstream for e.g. dpkg and try to please *everyone* (just picture wishlist bugs against dpkg to nativly handle eggs and jars =0) ps. sorry if you get this twice.. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: sphinxsearch
I'm not a DD just wanted to see how to used docbase... But here are my 2 russian kopejkas. 2009/5/13 Tom Simnett : > Hope I'm not missing anything else now :) (New version uploaded again) > > Tom 1) rules - have you though of using dh7 style? (just %: dh @ with overrides) Or is there a _specific_ reason for debhelper 5 compatability? (lenny has debhelper 7 so it should be easy to backport) With debhelper 7 your rules will become much smaller. See man dh and other revelant for details. 2) rules - please consider running the test suite here (*hint* needs a variable in rules) 3) copyright - there is DEP#5 proposal for the machine parsable copyright file (it's not a rule or anything). If you like it try using it. [1] 4) changelog I'm sure that it should be (Closes: #N) e.g. [2] 5) control - are you using a version control system for your packaging? (I would suggest you do, bzr-builddeb and git-buildpackage are very strong contenders and both support pristine-tar, ie. saving a small binary delta to regenerate an identical tarball at build-time) 6) control - I'm sure your long description is too short (it's abscent). Now running lintian with following options -i -I -v -E --pedantic gives this: P is for pedantic (eg. not all agree on it); X is for eXperimental - lintian might got it wrong; I is Informational. I's you should correct. P and X - choose and pick N: Processing source package sphinxsearch (version 0.9.8.1-1) ... P: sphinxsearch source: direct-changes-in-diff-but-no-patch-system Makefile.in and 4 more- N: Processing binary package sphinxsearch (version 0.9.8.1-1) ... P: sphinxsearch: copyright-refers-to-symlink-license usr/share/common-licenses/GPL N:Severity: pedantic, Certainty: possible I: sphinxsearch: extended-description-is-probably-too-short X: sphinxsearch: spelling-error-in-binary ./usr/bin/sphinx-indexer succesfully successfully X: sphinxsearch: spelling-error-in-binary ./usr/bin/sphinx-indexer ment meant X: sphinxsearch: spelling-error-in-binary ./usr/bin/sphinx-search ment meant X: sphinxsearch: spelling-error-in-binary ./usr/bin/sphinx-searchd succesfully successfully X: sphinxsearch: spelling-error-in-binary ./usr/bin/sphinx-searchd ment meant X: sphinxsearch: spelling-error-in-binary ./usr/bin/sphinx-spelldump ment meant P: sphinxsearch: no-upstream-changelog [1] http://dep.debian.net/deps/dep5/ [2] http://packages.debian.org/changelogs/pool/main/d/debhelper/current/changelog -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: alarm-clock (updated package, adoption, targetted for experimental)
2009/5/13 Ryan Niebur : > For experimental because it's a rewrite in C and doesn't yet have all > of the features of the python version. Upstream recommended leaving > the python version in unstable for now. > I thought upstream was dead. Is it same upstream Also with python version CPU usage would go to 100% when playing music for alarm. That's why I've stopped using it. Does this happen with C version as well? Otherwise I'll try it out. I'm NOT a DD ;-) Just a user. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Help with makefiles
I have a lot of manpages written in pod and instead of 15 lines in rules I want to have just 3. It's not quite working though =((( ./debian/rules -n build/manpages for i in addld mkfastmod mod2imp osis2mod imp2gbs imp2ld imp2vs vpl2mod vs2osisref tei2mod xml2gbs installmgr; do pod2man --release= --center "" -n `echo | tr '[a-z]' '[A-Z]'` debian/.1.pod > (i).1 done ./debian/rules build/manpages for i in addld mkfastmod mod2imp osis2mod imp2gbs imp2ld imp2vs vpl2mod vs2osisref tei2mod xml2gbs installmgr; do /bin/sh: Syntax error: end of file unexpected make: *** [build/manpages] Error 2 Any suggestions? in acctual rules file tabs *are* present...... -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
2009/5/19 Matthias Julius : > Matthias Julius writes: > >> I am looking for a sponsor for the new version 1.0~beta2-1 >> of my package "krecipes". >> >> It builds these binary packages: >> krecipes - recipes manager for KDE >> krecipes-data - recipes manager for KDE - data files >> krecipes-doc - recipes manager for KDE - documentation >> >> Krecipes is a KDE application designed to manage recipes. It can help you to >> do your shopping list, search through your recipes to find what you can do >> with available ingredients and a diet helper. It can also import or export >> recipes from files in various format (eg RecipeML or Meal-Master) or from >> databases. >> >> The package appears to be almost (see below) lintian clean. >> >> The upload would fix these bugs: 473367, 478030, 513860 >> >> The package can be found on mentors.debian.net: >> - URL: http://mentors.debian.net/debian/pool/main/k/krecipes >> - Source repository: deb-src http://mentors.debian.net/debian unstable main >> contrib non-free >> - dget >> http://mentors.debian.net/debian/pool/main/k/krecipes/krecipes_1.0~beta2-1.dsc >> >> I would be glad if someone uploaded this package for me. >> >> I have to give you some background information. Maintainer for >> krecipes is actually "Debian KDE Extras Team >> ". Unfortunately, this is list >> is mostly dead except from forwarded messages from BTS or PTS. A >> number of mails I (and others) sent there got no response. >> >> Krecipes has not been maintained for over 2 years and the MIA team has >> requested the removal of the only Uploader a couple of months ago >> (#513860). Therefore, I would consider krecipes effectively orphaned, >> allthough not officially. Are there any formal steps I should >> undertake to take over maintainership for this package? > > I would really appreciate if someone could either help me to get my > krecipes package into Debian. > > I am just not quite sure whether it is OK to hijack a package like > that from an unresponsive packaging team. Should I ask QA to orphan > the package? > > Matthias > I'm not a DD, but I think the correct way is to ping MIA team about it and then after 2 weeks time you ping them again and they do a little chat and come up with a solutions usally in your favor. Try that, cause they record stuff in wnpp and then you can go on and adopt stuff. i think the email was m...@debian.org but double check that (Developer's Reference / New maintainer's guide one of them had a chapter dealing with unresponsive developers.) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposal for template for uploads
>> --- >> >> The package can be found at : >> - URL: >> http://example.com/debian/pool/main/f/foo >> - Source repository: >> deb-src http://example.com/debian unstable main contrib non-free >> - dget line: >> dget http://example.com/debian/pool/main/f/foo/foo_version-revision.dsc >> debcheckout with revision flag / tag ??? (this might work for git / bzr which support signed revisions / tags) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Swig and Java bindings packaging
I'm maintaining a C++ library. They have SWIG (python) and Java (dunno how) bindings which are not packaged right now. I would greatly appreciate if someone can point out good examples of packaged python-swig and / or Java bindings for libraries? I'm a bit stuck cause the bindings are not integrated into autofoo build system (it's not just additional flag to configure) and i struggling to get my head around how to link against a library which has just been build and not yet installed. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Swig and Java bindings packaging
2009/5/22 Felipe Sateler : > Dmitrijs Ledkovs wrote: > >> I'm maintaining a C++ library. They have SWIG (python) and Java (dunno >> how) bindings which are not packaged right now. >> >> I would greatly appreciate if someone can point out good examples of >> packaged python-swig and / or Java bindings for libraries? >> >> I'm a bit stuck cause the bindings are not integrated into autofoo >> build system (it's not just additional flag to configure) and i >> struggling to get my head around how to link against a library which >> has just been build and not yet installed. >> > > SWIG is an interface generator for C++ into several languages. So probably > both interfaces in your program are SWIG-based. > > If the interfaces are not hooked into the package build system, then you > will probably have to invoke swig directly to generate them. My package > csound uses SWIG to generate Java, Python and Lua bindings. It uses scons, > however. > What package is this? > > -- > Felipe Sateler > It's libsword7 (currently only in experimental) Or newer upstream release bzr branch lp:~pkgcrosswire/libsword/main dget https://edge.launchpad.net/~pkgcrosswire/+archive/ppa/+files/sword_1.6.0-1~31~09.10.dsc -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
About get-orig-source - latest or always the same?
Dear mentors I have a question about policy with respect to get-orig-source and it's use with the DFSG tarballs. The policy 4.9 says: "This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory." Debian Reference 6.7.8.2 says: "A repackaged .orig.tar.gz. must be documented in the resulting source package. Detailed information on how the repackaged source was obtained, and on how this can be reproduced must be provided in debian/copyright. It is also a good idea to provide a get-orig-source target in your debian/rules file that repeats the process, as described in the Policy Manual, Main building script: debian/rules." So if currently the latest upstream release of sword is 1.6.0. Hence the version we are packaging is 1.6.0+dfsg-1. Now imagine our team finished packaging this version and it has landed in the stable release. Upstream by this time released 1.7.1. And our team packaged 1.7.1 and it is in unstable. So what should get-orig-source target do: 1) In both stable and unstable: Grab 1.7.1 and turn it into 1.7.1.dfsg 2) In stable: Grab 1.6.0 and turn it into 1.6.0.dfsg; in unstable grab 1.7.1 and turn it into 1.7.1.dfsg 3) Parse debian/changelog and create the tarball for the latest version listed there Cause now in our "big team" of two collaborators we have disagreement about this =D -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Confused by .dirs, .install etc
2009/5/24 Richard W.M. Jones : > I have a problem building a library, starting with a dh_make template. > The basic problem seems to boil down to files don't get moved from > DESTDIR (debian/tmp) into the actual packages, so the final *.deb > packages are empty. > > It seems like the .dirs and .install files in debian/ are > something to do with this process. However I cannot find where in > Debian policy these are documented ... > Debian policy talks about the final result only and there are many ways to get there. You are using debhelper to get there so read debhelper documentation # general man debhelper man dh # about debian/*.dirs man dh_installdirs # about debian/*.install man dh_install # also read for a few others man dh_install* > Any pointers? > or use bash/man completion and read man dh_* they are all very similar from UI point of few and let you achieve many things > Rich. > ps. @redhat.com. Nice =D i still don't have @ubuntu.com nor @debian.org email addresss. =```((( working on it though > -- > Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones > Read my programming blog: http://rwmj.wordpress.com > Fedora now supports 75 OCaml packages (the OPEN alternative to F#) > http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora > -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: sphinxsearch
Again I'm not a DD. > Dmitrijs Ledkovs wrote: >> 1) rules - have you though of using dh7 style? (just %: dh @ with > > This is because I need a package for etch too and the one package works > across the board without problems using dh5. Is this the wrong way to do it? > That's fine. As long as you have a valid reason =D >> 2) rules - please consider running the test suite here (*hint* needs a >> variable in rules) > > I've been looking around for this but can't find any documentation for it. > (sorry I've been referring to CDBS / dh(1)) basicly after build target is finished you should be able to run the test-suite and it should pass. Look through upstream documentation on how to run it. In autotools based packages it's usually "check" target in upstream Makefile and sometimes additional "installcheck" target. So yeah in CDBS there is a variable to store the name of the testusuite target. In dh(1) there is dh_auto_testsuite (from memory might be wrong) which deal with these things. >> 5) control - are you using a version control system for your >> packaging? (I would suggest you do, bzr-builddeb and git-buildpackage >> are very strong contenders and both support pristine-tar, ie. saving a >> small binary delta to regenerate an identical tarball at build-time) > > I'm using git-buildpackage. > Then you should add Vcs-git: and Vcs-browse; tags to your control. So that debcheckout will work for your packages. Look at some other git maintained debian packages in their control field. > Lintian now shows as clean with one more pedantic bit and the X: notes > I'll report upstream and get fixed there. > > Tom -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Libary Packaging
2009/5/29 Yonah Brendon Franklin : > Hi, > i still have problems to understand how to build libraries. > > why do i have only directories and no libfiles? > > where can i find this? > > yonah > try building the software without debian/ dir at all. (as if you are trying to compile something as a direct upstream users) this will give you good idea about the upstream build-system. Then set the correct configure/compile/install flags such that the software is compiled and linked with prefix /usr/ but set the destanation directory for the install target to debian/tmp/ After you think you have done this correctly try running ./debian/rules build this should build everything that needs building after that you can try ./debian/rules install (if you create such target) or you should be able to run ./debian/rules binary this step should install everything what needs to be install into debian/tmp if you see not enough files in debian/tmp then probably some of your configure flags were wrong. If you see eveything what's needed in debian/tmp then move onto next step. dh_install* commands do the dirty work of sorting out what goes into which package. So you need to provide correct lists of files you want to end up in which package for dh_install(1) you create debian/libfoo1.install and list all run-time required files; then you'll probably also need debian/libfoo-dev.install and you'll put header's there (so and you have one of those files for each package in the debian/control) based on those files dh_install sorts stuff into packages which are located in debian/package_name check those folders after you have run ./debian/rules binary to see what will end up in them. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITS: arc-colors, gnome-colors, shiki-colors are ready
Hi Evgeni (Privet) 2009/5/29 Evgeni Golov : > Hi Benjamin, > > On Fri, May 29, 2009 at 02:31:38PM +0200, Benjamin Drung wrote: >> >> I would be glad if someone uploaded this package for me. > > I'll have a look at these the next days (prolly not before thuesday > though). So is that Tuesday or Thursday?? =D > As the old packages were in a very good shape, I'm quite sure I'll be > able to upload this versions after I checked the copyright stuff. > BTW, is there no more shiki-colors package? only -murrine? > > Regards > Evgeni -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: poco (updated package)
2009/6/1 Krzysztof Burghardt : > 2009/5/31 Krzysztof Burghardt : >> 2009/5/27 George Danchev : >>> The only thing I'm not happy with is the staticaly linked zlib with >>> libpocofoundaton shared object and its debug variant. Can we please fix that >>> to dynamically link with the system provided libz, or is there any reason >>> I'm >>> not aware of to use the zlib version provided by poco's Foundation module? >> >> I will ask upstream. > > Upstream is generally against using system (3rd party) zlib: > https://sourceforge.net/tracker/index.php?func=detail&aid=2799209&group_id=132964&atid=725712 > I'm not a Debian Developer but I've met this one with one of my "upstreams" as well. The reasoning is very vague. My upstream has been keeping an ancient copy of zlib in their tree/releases just because it's *easier* for them to build on Windows. I did the crude way simply purged the library and tried building. It worked =D I've never playing around with cmake (it looks like your upstream is using that) but it should be very easy to fix if it fails to build in pbuilder cause you will have error messages. From that point on it's detective and efficient googling work as well as $ apt-get source package_to_borrow_packaging_ideas_from. Good luck =D -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITR: febootstrap
2009/6/1 Richard W.M. Jones : > On Thu, May 28, 2009 at 01:26:32AM +0530, Y Giridhar Appaji Nag wrote: > [...] >> Suggestions: >> >> - It is usually a good idea to maintain the debian packaging also in a VCS. >> Even though this package is simple, since you are also the upstream, I was >> wondering if you you would be interested in maintaining the Debian >> packaging >> also in upstream git (possibly on a debian branch). In case you implement >> this suggestion, please add Vcs-Git and Vcs-Browser to debian/control. > > I'm of course maintaining this package in my own VCS. Is the suggestion > to add the debian/ subdirectory to my upstream git: > > http://git.et.redhat.com/?p=febootstrap.git;a=summary > > I thought it was bad for upstream to have their own debian/ > subdirectory? > Yeap bad. But there is a tool called git-buildpackage which is used to aid packages to maintain their work. Branch the revision you are trying to package into a branch called "debian" and commit your packaging activitry onto that branch. And pull into "debian" branch new upstream releases =D just google about git-buildpackage a few how-to's should show up. Basicly it can grab / create correct tarballs and perform build (debuild / pbuilder) automagically without messing up your branch. >> - Since you are using debhelper >= 7, have you considered using "dh" (your >> debian/rules will be very simple). > > Hmmm, manpage for 'dh' looked a bit complicated ... > well when you have the default rules file (which looks like that(?)) %: dh $@ just run "dh binary --no-act" and it will show which dh_* commands it what sequence it will run for that target. After this you fix up / tune any dh_* rule you want with the override_dh_* target. When you enter override rules the dh target --no-act will substitute your override targets. Usually this results in much smaller rules files and very readable as well cause the override targets explicitly emphasise what is unique about your package. > Rich. > -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Package is RFA, got a single update
2009/6/2 Dominik Bruhn : > Hy, > situation: The package obexpushd is RFA. It currently has some > debian-related bugs and a security problem. There is also a new upstream > version (not packaged but fixing the security problem). > > I got a new package ready, fixing all debian-bugs, updating to the most > recent upstream version and updating the debian/rules and > debian/controls. > > Thanks > -- > Dominik Bruhn > mailto: domi...@dbruhn.de > Read up about WNPP [1] In short if you want to adopt this package rename the RFA bug into ITA bug. Change the maintainer field to your name in the debian/control. And in debian/changelog mention that you are a new maintainer with Closes: #the_ITA_bug_number. [1] http://www.debian.org/devel/wnpp/ -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITS: arc-colors, gnome-colors, shiki-colors are ready
2009/6/5 Bernhard R. Link : > * Benjamin Drung [090605 01:59]: >> It's sad, that public domain does not exists in Germany > > In the same sense public domain does not exist in Germany, copyright > does not exist in Germany either. > > I've asked multiple times and not yet got a single argument why > "I herby place this and that in the public domain" could see any danger > to be misunderstood or invalidated by a German court. > http://en.wikipedia.org/wiki/Wikipedia:Public_domain#Rule_of_the_shorter_term Sorry no better source. I quite like German Copyright Law even though it's a bit of a pain for the US originated open-source public domain stuff. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITS: arc-colors, gnome-colors, shiki-colors are ready
2009/6/5 Bernhard R. Link : > * Dmitrijs Ledkovs [090605 14:01]: >> > I've asked multiple times and not yet got a single argument why >> > "I herby place this and that in the public domain" could see any danger >> > to be misunderstood or invalidated by a German court. > >> http://en.wikipedia.org/wiki/Wikipedia:Public_domain#Rule_of_the_shorter_term >> >> Sorry no better source. > > Only thing I can find there is that the "years after authors death" > is the same without looking where the author lived. And it also says > that the USA has the same behaviour in this regard. > > I doubt we will find useable software anytime soon where the > software is in the public domain because the author is many decades > dead, but I was speaking about people giving up their copyrights. > > Hochachtungsvoll, > Bernhard R. Link "However, some countries make exceptions to this rule. A notorious case is Germany, which has had a bilateral treaty with the U.S. governing copyright since January 15, 1892. That treaty, which is still in effect, defined that a U.S. work was copyrighted in Germany according to German law irrespective of the work's copyright status in the U.S, and it did not contain a "rule of the shorter term". In one case, a German court therefore decided that a U.S. work that had fallen into the public domain in the U.S. was still copyrighted in Germany in 2003 in spite of §7(1) of the EU directive." Good enough for me. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITS: arc-colors, gnome-colors, shiki-colors are ready
2009/6/6 Bernhard R. Link : > > To say what? All this says, especially with the context you omitted, > that a work will not enter public domain N years after death of the > author for N the value from the authors home country but only when the > number of years by German law are reached. > > And given the list also linked on that page, that is true for many > countries, including the US. If I misread anything, please tell me. > But there is nothing at all saying that a "I place this work in the > public domain" would have any more problems in Germany than in the US. > > Hochachtungsvoll, > Bernhard R. Link Ok, sorry, I did missunderstood this. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
Can you take discussions like these to d-d? Cause I think any prospective packagers just turn away after reading threads like these. Is it possible to keep these list for mentees to talk to sponsors about questions problems and RFS and not use it as d-d death match platform. Could you please discuss your issues behind the scene and present only coherent/ or per-sponsor opinions here? Eg. Some of the QA people would like to advertise QA uploads here is a mail from them. But generally please still follow the usual packaging guides and the usual sponsor requirements. Cause I follow this list to learn tips & tricks from everything mentors point out about packages. Also it is very interesting to see reply's from sponsors about valid packaging/technical questions not covered elsewhere. So far from this thread I've learned nothing except that there are QA uploads and I better RFS one cause it's all double-standards. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to build GCJ/GDC ?
Hello Igor, On 08/06/12 22:18, Игорь Пашев wrote: > I'd like to make custom build of GCJ. > > Here is a source package page: > http://packages.debian.org/source/sid/gcj-4.7 > > but the VCS URL is for GCC. > > I've already built GCC and know all that package (gcc-4.7) well. > And now I wonder how to use it to build GCJ. > > Should I put into root dir tarball of GCJ sources instead of GCC? The gcc/gcj/ada/etc packaging is rather interesting. The VCS URL should point to an svn repository which, after updating debian/changelog and debian/control can build a few source packages for bootstrapping the gcc toolchain, including the gcj. If you just want to rebuild gcj, use apt-get source gcj-4.7 If you want to contribute to gcj packaging, prepare to learn a lot of funky Makefile magic of the whole gcc packaging (cc is 'compiler collection' which includes the gcj compiler) There should be a README.source in the repository or similar explaining a little bit how that packaging machinery works. It is not a trivial package by any means. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: How to build GCJ/GDC ?
Ok, On 09/06/12 00:01, Игорь Пашев wrote: > Dmitrijs, thanks for you answer :-) > > I've already built GCC from VCS with some non-trivial changes and bugs > (#653255) > (I'm building on a Solaris based system, with all linker, libs, > fixincludes and GCC specs hell ;-) > > I just wonder how to build GCJ from the same VCS (as it mentioned via > source package page) > 3 steps: 1) change debian-changelog top line to read gcj 2) run ./debian/rules control 3) good luck... build the source package, build the package You will need gcc-4.7-source package for this to work. Regards, Dmitrijs. > 2012/6/9 Dmitrijs Ledkovs mailto:x...@debian.org>> > > Hello Igor, > > On 08/06/12 22:18, Игорь Пашев wrote: > > I'd like to make custom build of GCJ. > > > > Here is a source package page: > > http://packages.debian.org/source/sid/gcj-4.7 > > > > but the VCS URL is for GCC. > > > > I've already built GCC and know all that package (gcc-4.7) well. > > And now I wonder how to use it to build GCJ. > > > > Should I put into root dir tarball of GCJ sources instead of GCC? > > The gcc/gcj/ada/etc packaging is rather interesting. The VCS URL should > point to an svn repository which, after updating debian/changelog and > debian/control can build a few source packages for bootstrapping the gcc > toolchain, including the gcj. > > If you just want to rebuild gcj, use apt-get source gcj-4.7 > If you want to contribute to gcj packaging, prepare to learn a lot of > funky Makefile magic of the whole gcc packaging (cc is 'compiler > collection' which includes the gcj compiler) > > There should be a README.source in the repository or similar explaining > a little bit how that packaging machinery works. > > It is not a trivial package by any means. > > -- > Regards, > Dmitrijs. > > > -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Creating files in /etc/udev/rules.d/ while install a package
On 18/06/12 19:13, Joachim Wiedorn wrote: > Hello! > > Is it allowed to create a file into /etc/udev/rules.d/ while installing > a package? The point comes out in package capi4hylafax which need an > symlink /dev/faxCAPI but until now the admin must create it by hand. > No, it is not. You can use /lib/udev/rules.d instead. /etc/udev/rules.d is for administrator to override the udev rule the package ships in the /lib/udev/rules.d -- Regards, Dmitrijs. -- 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/4fdf7cf3.4000...@debian.org
Bug#678705: RFS: e2defrag/0.80 ITP: #678598
Hello Phillip, Thanks for picking up this package. Here are some comments == ITP == The ITP was not sent to the debian-devel mailing list. Please use report-bug in the future or add pseudo-header: X-Debbugs-CC: debian-de...@lists.debian.org Please forward your ITP to debian-devel. == bugs == Bugs there were closed due to removing the package from the archive should be still addressed. As bugs was the reason to remove the package from the archive in particular: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396449 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401622 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324555 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389231 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=169584 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=235498 If these are fixed, mention (Closes: #ZZZYYY) in the debian/changelog. == debian packaging == Fix the following notices from lintian: > P: e2defrag source: unversioned-copyright-format-uri > http://dep.debian.net/deps/dep5 > W: e2defrag source: out-of-date-standards-version 3.9.2 (current is 3.9.3) > W: e2defrag: script-with-language-extension usr/sbin/dump2inodes.py > I: e2defrag: hyphen-used-as-minus-sign usr/share/man/man8/e2defrag.8.gz:123 > I: e2defrag: hyphen-used-as-minus-sign usr/share/man/man8/e2defrag.8.gz:129 > I: e2defrag: spelling-error-in-manpage usr/share/man/man8/e2defrag.8.gz > ommitted omitted > I: e2defrag: hyphen-used-as-minus-sign usr/share/man/man8/frag.8.gz:69 > W: e2defrag: binary-without-manpage usr/sbin/dump2inodes.py > E: e2defrag: python-script-but-no-python-dep usr/sbin/dump2inodes.py You can get more information about them by running lintian with: lintian -i -I --pedantic -E -v *.changes If you manage packaging in a VCS, please add Vcs-* headers. == source format == Usually upstream makes tarball releases, which then can be packaged. Please do, and use 3.0 (quilt) source format. Bzr-builddeb has support for split mode: http://jameswestby.net/bzr/builddeb/user_manual/split.html Or you can use: bzr export -rtag:0.80 --per-file-timestamps e2defrag-0.80.tar.gz To create a tarball which will always have the same checksum. I would like you to consider stop using native package version and instead make 0.80 release and package it as 0.80-1. -- Regards, Dmitrijs. -- 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/4fe650f8.8050...@debian.org
Bug#678705: RFS: e2defrag/0.80 ITP: #678598
Dear Phillip, Thank you for replying to all the comments and resolving issues quickly. I haven't checked them yet, but I am sure they are fine now. See further comments: On 24/06/12 03:50, Phillip Susi wrote: > >> Bugs there were closed due to removing the package from the archive >> should be still addressed. As bugs was the reason to remove the package >> from the archive in particular: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396449 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401622 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324555 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389231 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=169584 >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=235498 >> >> If these are fixed, mention (Closes: #ZZZYYY) in the debian/changelog. > > They are already all closed and archived. > Let me rephrase. Is upstream aware of the above bugs which affected the last version of defrag in debian, which were not fixed in the upstream code? (the bugs were closed and archived, simply because the package was removed from debian, not because they were fixed upstream) If upstream is aware of the above bugs, have they been fixed or tracked in the upstream bug tracker/TODO items/etc? (I see now that you have clarified that the ext3/4 support was added, but it was not obvious to me simply by reading the debian/changelog) == Readiness == Generally, Debian packages stable releases of software. At the current state is this package ready for unstable or better suited for experimental? Has it seen wider testing / user base? (e.g. did you post an announce to ext-dev mailing lists? LWN.net? similar sites). This is a bit of chicken and egg problem: no package no user base, no user base no package. I believe that inclusion of this package in Debian will increase testing. Do you believe this should be uploaded into experimental or unstable? -- Regards, Dmitrijs. -- 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/4fe7a550.4020...@debian.org
Bug#678705: RFS: e2defrag/0.80 ITP: #678598
On 24/06/12 23:58, Nicholas Breen wrote: > On Sun, Jun 24, 2012 at 02:31:23PM -0400, Phillip Susi wrote: >> On 06/24/2012 12:00 PM, Roger Leigh wrote: >>> This was always a tool which needed to be used with great caution, >>> and was removed for good reason. Is this safe to use with all >>> ext2, ext3 and ext4 filesystems? >> >> Obviously there may be bugs, and a crash in mid defrag likely will leave you >> with a hopelessly corrupted fs, but yes, it is working with all modern ext4 >> features. I'm kicking around an idea to log enough information to allow for >> recovery after a crash, but this would significantly slow down the process. > > There is already an ext4-specific (depends on creation with -O extent) > e4defrag > tool in e2fsprogs since 1.42~WIP-2011-07-02-1. Is there a reason you would > use > one tool over the other? > The obvious, you would use e2defrag for ext2, ext3 & ext4 without extents. But the question which one to prefer for ext4 with extents still stands. -- Regards, Dmitrijs. -- 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/4fe7a5c7.2030...@debian.org
Bug#678705: RFS: e2defrag/0.80 ITP: #678598
On 25/06/12 02:14, Phillip Susi wrote: >> Generally, Debian packages stable releases of software. At the current >> state is this package ready for unstable or better suited for >> experimental? Has it seen wider testing / user base? (e.g. did you post >> an announce to ext-dev mailing lists? LWN.net? similar sites). >> >> This is a bit of chicken and egg problem: no package no user base, no >> user base no package. >> >> I believe that inclusion of this package in Debian will increase testing. >> >> Do you believe this should be uploaded into experimental or unstable? > > Exactly. I was planning on announcing it once it's in the archive to call > for testing and feedback. The usage of experimental is still unclear to me. > If it is in unstable then it will be synced to Ubuntu quantal as well, though > I suppose Ubuntu users can get it from my ppa if it is holding in > experimental for now. > Your decision whether you upload into Debian experimental or unstable should not be affected by other derivative distribution policies. You can request syncing packages from experimental into Ubuntu, but the package will still land in Ubuntu's new queue and require verification. You can always provide backports/ppa/etc regardless of the package status in the archive. Given above, unstable or experimental? -- Regards, Dmitrijs. -- 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/4fe8208c.9030...@debian.org
Bug#678705: RFS: e2defrag/0.80 ITP: #678598
On 25/06/12 14:34, Phillip Susi wrote: > On 6/25/2012 4:25 AM, Dmitrijs Ledkovs wrote: >> Your decision whether you upload into Debian experimental or unstable >> should not be affected by other derivative distribution policies. You >> can request syncing packages from experimental into Ubuntu, but the >> package will still land in Ubuntu's new queue and require verification. >> You can always provide backports/ppa/etc regardless of the package >> status in the archive. >> >> Given above, unstable or experimental? > > I'm still not sure why one would want to use experimental instead of > unstable. It seems like it's just one more hoop people have to jump > through ( adding one more entry to sources.list ) to use the package. > I'm not necessarily opposed to it, I just don't see the benefit. > > Correct me if I'm wrong, but isn't experimental for testing a one off > hack you want a few specific people to try, but you know it would cause > breakage for other users and so would not be appropriate for unstable? > > If that's the case, then I'd say unstable is the place to go. > Depends. Generally Experimental is what you make of it. http://wiki.debian.org/DebianExperimental Many new upstream releases of large packages are cured in experimental first, because it introduces packages to the archive and allows using bts to file and track bugs. Many large libraries and softwares are packaged in experimental first, e.g.: gnome, kde stacks, gcc toolchain, minor libraries SONAME bumps. To ease testing against other packages (e.g. ftbfs in experimental with libfoo+1) and ease testing the package by experienced developers and users. Uploading to experimental, means that a package will not be a candidate for automatic transition into a stable release. This can also be achieved by opening a "sticky" RC bug. "Don't close, until maintainer is happy for the package to transition". When the archive is frozen, experimental is used to package all new software, to allow unstable->testing uploads & transitions without going through testing-proposed-updates. To sum up, experimental is a tool for a maintainer to govern the per-package release cycle on top of debian. I can see how you want it in unstable, and I am fine to sponsor it there. -- Regards, Dmitrijs. -- 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/4fe86be3.40...@debian.org
Re: issues with packaging Clozure Common Lisp (ccl.clozure.com) for Debian
On 17/07/12 13:28, The Fungi wrote: > On 2012-07-17 11:38:32 +0530 (+0530), Faheem Mitha wrote: > [...] >> CCL requires itself to build. Since it is not currently in the >> Debian archive, that raises the question of how this should >> happen. > [...] > > I'm not sure how much closer that's gotten to being a usable > proposal yet. I hunted around for documentation specific to > introducing a new self-building compiler package into Debian, but > didn't have much luck. Hopefully one of the DDs on this list can > point you to something slightly more appropriate. > Out of self-building compilers we have gcc compiler suite (full bootstrap), or ada compiler specifically (which requires -1 ada to compile). One of the recent bootstraps done, was multiarch bootstrap as outlined here: http://wiki.debian.org/Multiarch/Bootstrapping Or the mingw-w64 gcc crosscompiler, which has documented it's bootstrap: http://anonscm.debian.org/gitweb/?p=collab-maint/gcc-mingw-w64.git;a=blob;f=debian/README.source;h=697d003e76d9afe20a40556bc619cc5e30a3c0ed;hb=HEAD -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#682893: RFS: freefoam/0.1.2-1 (for experimental)
Hello Michael,
Thank you for your work!
First small comment, instead of adding debian-science to CC, next time
use X-Debbugs-CC. The difference is: if in CC reply-all adds submit@ and
you get a loop of filing new bugs, in X-Debbugs-CC only
##@bugs.debian.org will be in the loop.
Now about the rest follows:
On 26/07/12 19:52, Michael Wild wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "freefoam"
>
> * Package name: freefoam
> Version : 0.1.2-1
> Upstream Author : Michael Wild
> * URL : http://freefoam.sourceforge.net
> * License : GPL-3+ (+GFDL-NIV-1.2, permissive, PSF-2,
> LGPL-2.1+, BSD-4-clause, GPL-2)
> Section : science
>
> It builds those binary packages:
>
> freefoam - programs for Computational Fluid Dynamics (CFD)
> freefoam-dbg - programs for Computational Fluid Dynamics (CFD) -
> debugging symbols
> freefoam-dev-doc - software for Computational Fluid Dynamics -
> developers documentation
> freefoam-user-doc - software for Computational Fluid Dynamics -
> user documentation
> libfreefoam - libraries for Computational Fluid Dynamics (CFD)
> libfreefoam-dbg - libraries for Computational Fluid Dynamics (CFD) -
> debugging symbols
> libfreefoam-dev - libraries for Computational Fluid Dynamics (CFD) -
> development files
> python-freefoam - software for Computational Fluid Dynamics -
> Python files
> python3-freefoam - software for Computational Fluid Dynamics -
> Python3 files
>
> To access further information about this package, please visit the
> following URL:
>
> http://mentors.debian.net/package/freefoam
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x
> http://mentors.debian.net/debian/pool/main/f/freefoam/freefoam_0.1.2-1.dsc
>
> More information about FreeFOAM can be obtained from
> http://freefoam.sourceforge.net.
>
> Changes since the last upload:
>
> * [84c7923] New upstream version 0.1.2
> * [162a878] Removed debian/patches/spelling.diff. Fixed in upstream.
> * [881573d] Removed debian/patches/copyright.diff. This information
> belongs into debian/copyright
> * [d834177] Removed debian/patches/userd.diff, upstream removed that
> part
> * [86c646e] Build man-pages from source, remove pre-compiled copies in
> debian/man1
> * [0452a37] Build HTML version of UserGuide, depend on libjs-mathjax
> * [e0e97d7] Added missing build-deps: graphviz
> * [0a2c68d] Move to straight dh sequencer with parallel builds enabled
> - The debhelper version present in Ubuntu precise doesn't contain
> the fix for the CPPFLAGS variable being ignored by CMake
> (#668813), so also add the manual workaround, just to make sure.
> - Removed build-depends on cdbs
> - Bumped minimum required version of debhelper to 7.0.50~.
> - Keep dh_installchangelogs from trying to install doc/changes/ as
> a file
> * [63668d2] Split off Python module into python{,3}-freefoam, move to
> dh_python*
> - Changed build-dependency from python-all to simply python added
> new
> - Build-depends on python3
> - Add X-Python{,3}-Version tags
> * [59cd2fe] Install private binaries into /usr/lib/freefoam/bin
> * [2a39577] Fix bogus lintian override
> * [1240767] Cleanup debian/control, fix Homepage/Source entries
> * [703e36b] Make debian/copyright complete, cleanup
> * [b87d5f9] Do not version plugins directory
> * [037f959] Properly assign files to correct package in
> debian/*.install. Requires new build-depends on bash-completion.
> * [2bdf7d5] Link docs of freefoam-{dev,user}-docs into
> /usr/share/docs/freefoam
> * [36a0288] Added debian/patches/disable-git-version-check.diff.
> Instead of querying git about the build number, use the Debian
> version.
> * [981346d] Override warnings about useless ldconfig calls
> * [e4c2b99] Add Michael Wild to the uploaders
> * [02f2ab1] Added
> debian/patches/fix-doc-urls-and-references-for-debian.diff.
> Update the installation directories accordingly in
> debian/freefoam-*-doc.install.
> * [63e9652] Added
> debian/patches/remove-hard-coded-python-modules-path.diff.
> For the build to work it is now required to set the PYTHONPATH
> environment variable in debian/rules.
> * [06d66a3] Add multiarch support
> * [658f053] Create debug-symbols packages {lib,}freefoam-dbg
> * [13446a4] Build hardened libraries and executables. This requires
> CMake/FOAMUtilities.cmake to be patched, otherwise it would be
> impossible to pass the PIE flags to the executables only in CMake.
> - Added d/p/add-DEB_EXE_COMPILE_LINKER_FLAGS-to-build-system.diff
> - Added a build-depends on hardening-includes
>
>
> Gerber van der Graaf, who originally packaged the freefoam-0.1.0-1
> package asked me to add myself
Re: Minutes from "Getting your packages into Debian"
On 14/08/12 11:49, Christoph Egger wrote: > Hi! > > David Bremner writes: >> QUOTE: Bremner: Gobby is not emacs, it's so sad. > > you know rudel-mode? ;-) > Somebody please make it work with etherpads! -- Regards, Dmitrijs. -- 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/502a2e49.4000...@debian.org
Re: [poke] RFS: xinetd
Heya, On 17 August 2012 14:44, Salvo Tomaselli wrote: > Let me know about the patches. > I've uploaded the corrected version > http://galileo.dmi.unict.it/~ltworf/xinetd/xinetd_2.3.14-8~exp1.dsc > > Thanks for the help. > I jumped out of bound and did upload -8 into experimental. Oh, well. I should fix this mess now =) I will take your -8~exp1 and upload as -9~exp1, not that -8 has landed into experimental. Sorry for the mess =) Regards, Dmitrijs. -- 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/canbhluhmqoujq-9brtjjsb6adlr7hiv40mkil8d-wmlhyxg...@mail.gmail.com
Re: Interaction between m.d.n. and Ubuntu
On 07/09/12 20:32, Boris Pek wrote: > Hi, > >> Unfortunately your package "..." was rejected because of the following >> reason: >> >> You are not uploading to one of those Debian distributions: oldstable stable >> unstable experimental stable-backports oldstable-backports >> oldstable-backports-sloppy >> oldstable-security stable-security testing-security stable-proposed-updates >> testing-proposed-updates sid wheezy squeeze lenny squeeze-backports >> lenny-backports >> lenny-security lenny-backports-sloppy lenny-volatile squeeze-security >> squeeze-updates >> wheezy-security unreleased >> >> Please try to fix it and re-upload. Thanks, > > How about adding Ubuntu names to the list? It can be useful. > > For example, I need to upload updated package with Ubuntu-specific patch. > This package will be uploaded into Ubuntu by avoiding Debian archive. > Ubuntu sponsorship can be done in two ways: 1) Open a bug, attach debdiff subscribe ~ubuntu-sponsors team 2) Branch lp:ubuntu/package, commit changes, push to back to lp:~/ubuntu/package/series/fix-for-bla, create merge proposal back into lp:ubuntu/package. In either case they end up in the sponsorship queue: http://reports.qa.ubuntu.com/reports/sponsoring/ Which has been growing a bit, due to freeze. Branches are nice, since they can have pristine-tar deltas in them ;-) -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Bug#705192: RFS: sosreport/2.3+nmu1 ITP
On 11 April 2013 06:13, Adam Stokes wrote: > sosreport (2.3+nmu1) unstable; urgency=low > > * NMU > * Package updated from git rev 1baf743 > > -- Adam Stokes Thu, 11 Apr 2013 00:50:51 -0400 > Why is this an NMU? I can't find sosreport in debian, did you mean to file ITP do a first time release "(2.3-1)" with Closes: #itpbugnumber? Regards, Dmitrijs. -- 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/canbhlugv3tvnwfqjtzcrm2hcbs3keygdjxcnl0autrtqt4x...@mail.gmail.com
Re: RFS: xinetd
On 15 June 2013 13:43, Salvo Tomaselli wrote: > Hello, > > I've just uploaded the new version of xinetd on mentors and it needs a > sponsor. > > http://mentors.debian.net/debian/pool/main/x/xinetd/xinetd_2.3.15-1.dsc > > it finally uses the latest upstream available version and closes 2 bugs with a > change in the init script. > uploaded. Regards, Dmitrijs. -- 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/canbhluiu8ar4kss7qoysx2apaaheukmtrpc07g3g2teodhv...@mail.gmail.com
Re: libraries compiled with clang
On 18 June 2013 11:05, Richi Lists wrote: > Hi everybody, > > gcc is the default compiler for debian, and all the libraries in the > repository are compiled with gcc. > clang is also in the repository. But if I want to compile anything other > than the simplest toy program, I also need libraries. Maintaining them > by hand is a nightmare if you're used to just apt-get them. > > So, is there any official guideline for inclusion of libraries compiled > with alternative compilers into the repository. > I read recently that one of the BSD distros switched to using clang as > the default compiler. I'm not suggesting that debian should do that. > I 'm just trying to find out what would be a good solution to have the > same ease of use in debian for compiling with clang as we have for gcc. > > I thought about the following alternatives: > 1) have them in the same repository > + easy to compile your app for gcc and clang at the same time > - adds a lot of duplication > - users might not know which versions of a lib they need > 2) handle it like a separate architecture > + good separation > + maybe possible to compile without modification of the packaging > - would result in n*m architecture/repositories > - separate installation required (unless multiarch could suffice here) > > Some time ago, I started by building some packages for the boost libs > compiled with clang. (http://blog.ulrichard.ch/?p=324) It's in no shape > to be included anywhere. > I'm just curious if its worth continuing in that direction, or if there > is already a consent for another solution. I'm not sure what it gains you. you can use gcc compiled shared libraries with clang and vice versa, there is no need to recompile the lib$world. That said, there have been multiple benchmarks done for various parameters and at the moment gcc still produces faster code / smaller binaries in debian and supports far more targets than clang. Look at clang availability: https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.2 http://buildd.debian-ports.org/status/package.php?p=llvm-toolchain-3.2 At the moment, I only choose to use clang during development when I do something stupid and I am confused about template errors. But do note that gcc-4.8 got so much better with template errors, it now also shows where/what/why came from. Regards, Dmitrijs. -- 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/CANBHLUggee=turuyrsoftr6xuoca77i0gkhzpt4zq7fucea...@mail.gmail.com
Re: Enabling flags depending on buildd gcc version
On 18 June 2013 15:29, Franz Schrober wrote: > Hi, > > > is it possible with dh/debhelper to enabling specific compiler flags easily > depending on the gcc-defaults package/gcc version? Problem is the GCC 4.8 > version which currently needs -fno-aggressive-loop-optimizations until some > source code depending on some non-standard compliant behaviour are fixed. Just > adding this to DEB_CFLAGS_MAINT_APPEND will cause build failures on > architectures without GCC 4.8 (only used by default on amd64, armel, armhf, > hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386). > > I would like to avoid to write special autohell/cmake/custom configure tests > That's a job of configure scripts. testing compiler options is easy and well supported / easy to add a new one using upstream's scripts. Regards, Dmitrijs. -- 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/canbhlugbp3aov23_ksmykkeyuzuoxfpxqdkbutvypwu3woz...@mail.gmail.com
Re: using /usr/libexec directory
Heya, On 10 July 2013 15:16, Lucio Messina wrote: > > > Hi all. I am Lucio Messina, I'm Italian and I don't speak english very well. > > I tried to package a program that uses the /usr/libexec directory and lintian > gave this output: > > --- > W: easybashgui: non-standard-dir-in-usr usr/libexec/ > W: easybashgui: file-in-unusual-dir usr/libexec/easybashgui/easybashgui.lib > W: easybashgui: file-in-unusual-dir usr/libexec/easybashgui/easybashlib > --- > > Should I move the files in /usr/lib or can I ignore lintian tags? > > Thank you in advance. Move the files to use "usr/lib" instead. Nothing on debian uses libexec. Usually there is a configure option one can pass, e.g. --libexecdir=/usr/lib Regards, Dmitrijs. -- 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/canbhluism_rmohqy9evvoa5zl8+0gk1ragdf+y5cs+y0ssr...@mail.gmail.com
Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 23 November 2010 01:22, Jonathan Nieder wrote: > (+cc: the almost-defunct debian-toolchain@ list, for posterity's sake) > > Hi Stephen, > > Stephen Kitt wrote: > >> I'm working on packaging a new version of the MinGW-w64 toolchain, which >> allows 32- and 64-bit Windows software to be compiled as a cross-compiler >> target using gcc. > > Sounds neat. Have there been any efforts on integrating this work into > upstream GCC? > mingw-w64 do all they work upstream. All patches that were created mingw-w64 project are applied directly to binutils and gcc head. There is a pending patch to pthreads-win32. mingw-w64 is runtime, tools to generate headers and microsoft compatible runtime loadable library. There are also headers to support compilation against windows vista, windows 7 and directx but I haven't personally tested that. >> * binutils-mingw-w64, a simple binutils-source-based package providing >> binutils targetting MinGW-w64's triplets; > > Any examples for how this can be used directly? e.g., can simple > Windows toys in assembler be compiled this way, and can it help with > analyzing binaries from such systems? > The following projects (taken from mingw-w64 website) confirmed using ming-w64 based toolchain to provide windows releases: Hexen II: Hammer of Thyrion FFmpeg OpenSC Wine MAME (Yes, the arcade emulator!) ReactOS VideoLAN VLC pthreads OpenSSL wxWidgets Code::Blocks FLTK SBC Archiver OpenLisp GTK+ GIMP mpg123 Factor JPen iAuxSoft ReMooD Emerge Desktop libsndfile wxPerl PPMs zlib The R Project for Statistical Computing Perl (5.12.0 and later) Strawberry Perl (contains bundled mingw-w64 gcc toolchain) QuakeSpasm GNU SASL GnuTLS OpenFOAM MS MPI Libxml2 The assembler and binutils support is there. And you do can dissemble PE exe files and dll with binutils. I'm not sure whether binutils can by it self analyse .NET intermediate language code or whether mono install packages are required as well for that. >> * gcc-mingw-w64, a more complex gcc-4.5-source-based package providing gcc >> targetting MinGW-w64's triplets; > > I don't remember how far the dak work has proceeded in supporting this. :( > How is dak involved? This will be just a regular binary deb package. >> * mingw-w64, the MinGW-w64 development headers and libraries. > > That means libc, I guess. > yes, kind of. Microsoft compatible runtime (dll's) + headers. usually abriviated as crt. >> MinGW-w64 now has its own official triplets, differing from MinGW's which are >> what had been used so far in Debian with the gcc-mingw32 and co. packages. >> This is why new packages are needed > > Thanks for explaining. > >> Building the packages is slightly involved: >> 1. Build binutils-mingw-w64 and install it. > > So the first step could be to get this package alone in Debian. > >> 2. Extract gcc-mingw-w64, and change the debian/control and >> debian/rules.variant links so they point to debian/control.bootstrap and >> debian/rules.bootstrap respectively. >> 3. Build gcc-mingw-w64 and install the resulting gcc-mingw-w64-bootstrap >> package. >> 4. Build mingw-w64 and install the resulting mingw-w64-dev package. >> 5. Return to the gcc-mingw-w64 folder, and clean the build >> fakeroot debian/rules clean >> 6. Change the debian/control and debian/rules.variant links so they point to >> debian/control.full and debian/rules.full. >> 7. Build gcc-mingw-w64. >> >> Note that since mingw-w64-dev is "Architecture: all", this should only be >> required to prepare the first upload. > > Yagh. I guess Debian infrastructure does not take care of multi-package > bootstrapping scenarios so well. The general scheme seems sane; I > just have three suggestions: > > . It would be simpler to have only one debian/rules file, with a > makefile variable to control which packages get built. See the > binutils package for an example. > > . debian/rules is allowed to generate debian/control, so one would only > need one starting debian/control for this. See the binutils package > for an example. > Which packages do you want to generate from debian/rules? gcc-boostrap + gcc-full? or mingw-w64 and binutils as well? Parse debian/changelog, figure out whether we are bootstrapping the whole toolchain from a single package, or building one or the other component and then build it. This should work with quilt 3.0 source package with tarball componnents --generate-empty-upstream. > . Maybe an example script in mingw-w64-dev's debian/README.source would > be helpful for people trying to figure out how the bootstrap worked. > > It is nice that the dependency loop can be broken by uploading
Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 23 November 2010 12:17, Jonathan Nieder wrote: > Hi again, > > [out of order for convenience] > Dmitrijs Ledkovs wrote: > >> =) can you sponsor our work in the future? > > Only if I become DD. I have not applied yet, so you will probably > need someone else. > > That said, my experience has been that useful, policy-compliant > patches and packages tend to get integrated. Maybe one of the > many wine-using DDs will pick it up once this works well. > >> mingw-w64 do all they work upstream. All patches that were created >> mingw-w64 project are applied directly to binutils and gcc head. > > That's great. One possibility in the long run might be to package > this as part of the usual gcc and binutils packages, then. > I've tried it. Current debian-gcc packaging is generating debian/control using m4 and it assembles 3 possible source packages: gcc, gnat and gcj. Gnat and gcj build-depend on gcc-source package. debian-gcc is a bit specific to the native libc based toolchains and cross-toolchains using libc. I didn't manage to find an easy place to plugin mingw-w64 bootstrap into that packaging. It would be ideal to share packaging there, but right now it is not quite easy to do. Bintuils in the multiarch doesn't build assambler. So a separate binutils-mingw package will be needed. >> On 23 November 2010 01:22, Jonathan Nieder wrote: >>> Stephen Kitt wrote: > >>>> * binutils-mingw-w64, a simple binutils-source-based package providing >>>> binutils targetting MinGW-w64's triplets; >>> >>> Any examples for how this can be used directly? e.g., can simple >>> Windows toys in assembler be compiled this way, and can it help with >>> analyzing binaries from such systems? >> >> The following projects (taken from mingw-w64 website) confirmed using >> ming-w64 based toolchain to provide windows releases: > > Mm, that answers a different question. What I meant is, is a copy > of binutils-mingw without gcc useful for anything? > > Analogy: ordinary binutils without gcc is useful for: > > - compiling firmware and simple binaries written in assembler > > - objdump (see <http://bugs.debian.org/19471>) > >> The assembler and binutils support is there. And you do can dissemble >> PE exe files and dll with binutils. > > This could be useful sometimes, yes. > >>>> * gcc-mingw-w64, a more complex gcc-4.5-source-based package providing gcc >>>> targetting MinGW-w64's triplets; >>> >>> I don't remember how far the dak work has proceeded in supporting this. :( >> >> How is dak involved? This will be just a regular binary deb package. > > In the past people have proposed additional packages like gcc-mips > depending at build time on the gcc-source binary package. This way, > the archive would only need two copies (the .orig.tar.gz and the .deb) > of the gcc source, and variants building separately could reuse that. > > The problem with that it required separate work to follow the GPL. > Normally the archive software guarantees that (1) the precise source > package used to build each binary package is available and (2) the > build-time dependencies for packages in "main" are available in some > version from the Debian archive. So after building gcc-mips, > gcc-source could be updated, and the result would be that gcc-mips > binaries were available for download but the exact corresponding > source would not be. Avoiding this required some manual configuration > and there were some thoughts about how to make it automatic. > Aha. Now I see the point. Well native gcc packaging uses gcc-source build-dep and we now have continious debian snapshots via web archive so I think gcc-source of any version can be retrieved. I guess the package version should reflect which gcc-source was used during build. >>> . It would be simpler to have only one debian/rules file, with a >>> makefile variable to control which packages get built. See the >>> binutils package for an example. >>> >>> . debian/rules is allowed to generate debian/control, so one would only >>> need one starting debian/control for this. See the binutils package >>> for an example. >> >> Which packages do you want to generate from debian/rules? gcc-boostrap >> + gcc-full? or mingw-w64 and binutils as well? Parse debian/changelog, >> figure out whether we are bootstrapping the whole toolchain from a >> single package, or building one or the other component and then build >> it. This should work with quilt 3.0 source package with tarball >> componnents --generate-empty-upstream. > > Wh
Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 23 November 2010 13:00, Stephen Kitt wrote:
>> > mingw-w64 has a ton of warnings, all instances of non-standard-dir-in-usr
>> > or
>> > file-in-unusual-dir because it ships its headers and libraries
>> > in /usr/$target/{include,lib}.
>>
>> Sounds like a lintian bug.
>
> Probably not, since the directories aren't FHS-compliant. As far as
> I'm aware though there isn't an agreed-upon FHS-compliant directory
> structure for cross-compilers; you'd know more about that than me,
> given your existing involvement with the toolchain!
>
> Regards,
>
> Stephen
>
Well there are these documents:
http://fedoraproject.org/wiki/Packaging/MinGW
https://wiki.ubuntu.com/MultiarchSpec
https://wiki.ubuntu.com/MultiarchCross
http://wiki.debian.org/multiarch
http://lackof.org/taggart/hacking/multiarch/
I'm going to start to draft how our packaging policy will look like
and where we are going to stick our toolchain. And obviously i will be
asking questions a long the way about specific points of where do we
want what installed. Currently I like fedora packaging guidelines, but
without sys-root. I'm still not to sure where to stick compiled native
apps. E.g. after I compile gedit using mingw-w64 toolchain, how it's
debian package should look like? =) similarly for the cross-compiled
-dev packages.
--
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/aanlktik+rggzryevrigprg_hfs7llgkzq-mcj2ghk...@mail.gmail.com
Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 10 December 2010 21:29, Matthias Klose wrote: > [CC ing Marcin] > > On 23.11.2010 12:49, Dmitrijs Ledkovs wrote: >> >> On 23 November 2010 12:17, Jonathan Nieder wrote: >>> >>> Hi again, >>> >>> [out of order for convenience] >>> Dmitrijs Ledkovs wrote: >>> >>>> =) can you sponsor our work in the future? >>> >>> Only if I become DD. I have not applied yet, so you will probably >>> need someone else. >>> >>> That said, my experience has been that useful, policy-compliant >>> patches and packages tend to get integrated. Maybe one of the >>> many wine-using DDs will pick it up once this works well. >>> >>>> mingw-w64 do all they work upstream. All patches that were created >>>> mingw-w64 project are applied directly to binutils and gcc head. >>> >>> That's great. One possibility in the long run might be to package >>> this as part of the usual gcc and binutils packages, then. > > please no. Adding more packages and complexity to the native gcc and > binutils builds is a no-go. > Ok, agreed. We will be using gcc-source and/or various DEB_STAGE API to debian/rules from gcc-source. >> I've tried it. Current debian-gcc packaging is generating >> debian/control using m4 and it assembles 3 possible source packages: >> gcc, gnat and gcj. Gnat and gcj build-depend on gcc-source package. >> >> debian-gcc is a bit specific to the native libc based toolchains and >> cross-toolchains using libc. I didn't manage to find an easy place to >> plugin mingw-w64 bootstrap into that packaging. > > You might want to have a look at Marcin's cross-build packages, using the > gcc-, binutils- and eglibc- source packages. These may be currently test for > the arm-linux target only, but should be fixable for mingw too. > Yeap, I did have a little chit-chat with Marcin about arm-toolchain-base package of his. I have forked it and started working on it. It does assume that there is a debian port of the target-arch. Starting an unofficial mingw-i386 and mingw-amd64 ports are probably the best thing, since the cross-toolchain package will be more streamlined with other cross-toolchain packages and it would be much easier to build all the dev packages and later install them with xdeb / apt-cross / dpkg-cross / *dpkg multiarch* > And I would love to build the spu cross-toolchain the same way (using newlib > instead of glibc). > Ok. -toolchain-base method is the current winner. I will work on providing a cross-toolchain using similar method. Thanks for looking into this =) >>> In the past people have proposed additional packages like gcc-mips >>> depending at build time on the gcc-source binary package. This way, >>> the archive would only need two copies (the .orig.tar.gz and the .deb) >>> of the gcc source, and variants building separately could reuse that. > > imo the biggest advantage for such packaging is that both the native and > cross toolchain is based on the same source and patches. > >>> The problem with that it required separate work to follow the GPL. >>> Normally the archive software guarantees that (1) the precise source >>> package used to build each binary package is available and (2) the >>> build-time dependencies for packages in "main" are available in some >>> version from the Debian archive. So after building gcc-mips, >>> gcc-source could be updated, and the result would be that gcc-mips >>> binaries were available for download but the exact corresponding >>> source would not be. Avoiding this required some manual configuration >>> and there were some thoughts about how to make it automatic. > > this is already guaranteed by the gcj and gnat builds by only relying on the > tarball in the gcc-4.x-source package. > >> ok. I was playing around with this. My current plan is to try out: >> generating debian/control from debian/control.subpackage*.in files >> using sed magic and makefile if statements =) with following >> combinations: >> >> 1) binutils >> 2) gcc-bootstrap >> 3) mingw-w64 >> 3) gcc-bootstrap (skip) - mingw-w64 - gcc-full >> 4) complete toolchain in one go =) >> >> And generate appropriate debian/control in each case. Our >> debian/changelog might go haywire though. >> >> About source and binary package versions. Source packages will use >> sequential release numbers, while at build time binary packages will >> get appropriate binary version which matches corresponding versions of >> the *-source packages used during build. I do
Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 11 December 2010 16:40, Stephen Kitt wrote: > On Sat, 11 Dec 2010 17:28:10 +1030, Ron wrote: >> On Fri, Dec 10, 2010 at 10:29:24PM +0100, Matthias Klose wrote: >> > On 23.11.2010 12:49, Dmitrijs Ledkovs wrote: >> > >debian-gcc is a bit specific to the native libc based toolchains and >> > >cross-toolchains using libc. I didn't manage to find an easy place to >> > >plugin mingw-w64 bootstrap into that packaging. >> > >> > You might want to have a look at Marcin's cross-build packages, >> > using the gcc-, binutils- and eglibc- source packages. >> >> I wasn't aware of Marcin's work, but I also agree this is probably >> the best avenue to explore if these are all building from identical >> source. I believe Robert's original attempt even did exactly this, >> and I tried to point Stephen in this direction too when he first >> contacted me, but I think that point got lost, and I got too busy >> to point again in more detail immediately. > > I'm not sure whether it got lost or not, my packages (with Dmitrijs' > contributions) currently build-depend on binutils-source and gcc-4.5-source > and avoid duplicating anything from the original binutils and gcc packages; in > fact I went to some effort (see my bug reports against gcc-4.5-source, now > resolved) to make sure the resulting packages would not only use the tarballs > provided in the -source packages but also apply any relevant patches. > I was using the same strategy independly from Stephen with my original mingw-w64-toolchain package which is on launchpad. The only difference is that I was supporting both *-source packages and vcs checkouts for daily builds, which has now stalled due to bzr issues on launchpad. Overall the build strategy was about the same, sans some minor details. >> AIUI, the main problem with this is that the distro archive tools >> currently don't have good support for ensuring these 'binary' -source >> packages will remain available and linked to the derivative binary >> debs that might be built from them and uploaded to the distro. >> >> I believe ftp-master indicated to Robert that this could be fixed, >> but he went back to the quick and dirty duplication instead. If >> there are people with time to spend on this, talking to the archive >> maintenance people about what needs to be done for that, and when >> and how it might happen, is probably a productive step at this point. > > Indeed; I'm not sure what Matthias means by > > On Fri, Dec 10, 2010 22:29:24 +0100, Matthias Klose wrote: >> this is already guaranteed by the gcj and gnat builds by only relying on >> the tarball in the gcc-4.x-source package. > > I imagine this could mean that the gcj and gnats builds don't use the patches > in the gcc-4.x-source package, and only use the tarball which won't change > from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2 etc.)... That > seems a shame to me since the patches are useful, and it still leaves the > problem of having a package build using gcc-4.5-source 4.5-1 for example, and > then gcc-4.5-source being replaced with version 4.5.1-1 with a new tarball. > > Matthias, is that what you meant? > As far as i can see from the build-logs source uploads of gcj / gnat use corresponding -source package and they do apply updated patches from the new -source package. The tarball is changed rarely, instead svn-updates patch is regenerated on subsequent uploads by Matthias. > I'll take it up with ftpmaster as you suggest, Ron! > > The other solution based on Marcin's work, which is also readily supported by > the existing -source packages, requires that the target architecture be > understood by dpkg (as pointed out by Dmitrijs); that may be a worthwhile > goal, notably since it solves the problem of how to provide build packages > for the various libraries people find useful, but it's a much longer-term > goal as far as I can see... > And it also solve the gcc package splitting problem (cpp, gcc, gcj, gnat etc) I have created a reprepro for mingw-i386 and mingw-amd64 on my alioth account and I'm building mingw-i386 packages using dpkg-buildpackage using -a option. I have updated dpkg_share files. I will try bootstrapping the arch again in pbuilder based on Debian experimental and then start uploading. It would be best to have access to a mingw-w64 alioth project. I have submitted the request for that, but still haven't received a reply. But that is another issue. I'll start mingw-common package on collab-maintainance with helper scripts, policy and updated dpkg-share. Repurposing Marcin's package for mingw is still work in progress. > Regards, > > Stephen > -- 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/aanlktimhcszth58yx_=dsmafktff9jby9b_g�jc...@mail.gmail.com
Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 17 December 2010 13:45, Matthias Klose wrote: > On 11.12.2010 17:40, Stephen Kitt wrote: >> >> On Sat, 11 Dec 2010 17:28:10 +1030, Ron wrote: >>> >>> On Fri, Dec 10, 2010 at 10:29:24PM +0100, Matthias Klose wrote: >>>> >>>> On 23.11.2010 12:49, Dmitrijs Ledkovs wrote: >>>>> >>>>> debian-gcc is a bit specific to the native libc based toolchains and >>>>> cross-toolchains using libc. I didn't manage to find an easy place to >>>>> plugin mingw-w64 bootstrap into that packaging. >>>> >>>> You might want to have a look at Marcin's cross-build packages, >>>> using the gcc-, binutils- and eglibc- source packages. >>> >>> I wasn't aware of Marcin's work, but I also agree this is probably >>> the best avenue to explore if these are all building from identical >>> source. I believe Robert's original attempt even did exactly this, >>> and I tried to point Stephen in this direction too when he first >>> contacted me, but I think that point got lost, and I got too busy >>> to point again in more detail immediately. >> >> I'm not sure whether it got lost or not, my packages (with Dmitrijs' >> contributions) currently build-depend on binutils-source and >> gcc-4.5-source >> and avoid duplicating anything from the original binutils and gcc >> packages; in >> fact I went to some effort (see my bug reports against gcc-4.5-source, now >> resolved) to make sure the resulting packages would not only use the >> tarballs >> provided in the -source packages but also apply any relevant patches. >> >>> AIUI, the main problem with this is that the distro archive tools >>> currently don't have good support for ensuring these 'binary' -source >>> packages will remain available and linked to the derivative binary >>> debs that might be built from them and uploaded to the distro. >>> >>> I believe ftp-master indicated to Robert that this could be fixed, >>> but he went back to the quick and dirty duplication instead. If >>> there are people with time to spend on this, talking to the archive >>> maintenance people about what needs to be done for that, and when >>> and how it might happen, is probably a productive step at this point. >> >> Indeed; I'm not sure what Matthias means by >> >> On Fri, Dec 10, 2010 22:29:24 +0100, Matthias Klose >> wrote: >>> >>> this is already guaranteed by the gcj and gnat builds by only relying on >>> the tarball in the gcc-4.x-source package. >> >> I imagine this could mean that the gcj and gnats builds don't use the >> patches >> in the gcc-4.x-source package, and only use the tarball which won't change >> from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2 etc.)... > > yes. > >> That >> seems a shame to me since the patches are useful, and it still leaves the >> problem of having a package build using gcc-4.5-source 4.5-1 for example, >> and >> then gcc-4.5-source being replaced with version 4.5.1-1 with a new >> tarball. > > no, the tarball doesn't change. it's in the .orig.tar.gz. all other > patches/packging are synced with the gcc-4.5 package. Nothing is lost, all > patches are applied. > >> The other solution based on Marcin's work, which is also readily supported >> by >> the existing -source packages, requires that the target architecture be >> understood by dpkg (as pointed out by Dmitrijs); that may be a worthwhile >> goal, notably since it solves the problem of how to provide build packages >> for the various libraries people find useful, but it's a much longer-term >> goal as far as I can see... > > otoh, this approach breaks more often with updates on patches and packaging. > Manageable however. > I have been running the daily build of gcc-4.4 trunk, binutils-trunk with mingw-w64-trunk and there were no breakages (if something was broken it was fixed within 24h by any one of these packages). So I believe it will be manageable. I'm pending inclusion of mingw-w64 triplet. See debbug #606825. > Matthias > -- 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/aanlktimssl57wzvrr3sla16mw+9v6ilgroutl+z=i...@mail.gmail.com
Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)
On 19 December 2010 09:16, Stephen Kitt wrote: > On Fri, 17 Dec 2010 14:45:06 +0100, Matthias Klose wrote: >> On 11.12.2010 17:40, Stephen Kitt wrote: >> > I imagine this could mean that the gcj and gnats builds don't use the >> > patches in the gcc-4.x-source package, and only use the tarball which >> > won't change from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2 >> > etc.)... >> >> yes. >> >> > That >> > seems a shame to me since the patches are useful, and it still leaves the >> > problem of having a package build using gcc-4.5-source 4.5-1 for example, >> > and then gcc-4.5-source being replaced with version 4.5.1-1 with a new >> > tarball. >> >> no, the tarball doesn't change. it's in the .orig.tar.gz. all other >> patches/packging are synced with the gcc-4.5 package. Nothing is lost, all >> patches are applied. > > I must be misunderstanding something here then: > % dpkg-deb -c gcc-4.5-source_4.5.0-10_all.deb|grep tar > -rw-r--r-- root/root 52023076 2010-04-14 13:56 > ./usr/src/gcc-4.5/gcc-4.5.0-dfsg.tar.xz > % dpkg-deb -c gcc-4.5-source_4.5.1-1_all.deb|grep tar > -rw-r--r-- root/root 52073572 2010-07-31 16:20 > ./usr/src/gcc-4.5/gcc-4.5.1-dfsg.tar.xz > % dpkg-deb -c gcc-4.5-source_4.5.1-12_all.deb|grep tar > -rw-r--r-- root/root 52073572 2010-07-31 16:20 > ./usr/src/gcc-4.5/gcc-4.5.1-dfsg.tar.xz > % dpkg-deb -c gcc-4.5-source_4.5.2-1_all.deb|grep tar > -rw-r--r-- root/root 52182428 2010-12-18 13:38 > ./usr/src/gcc-4.5/gcc-4.5.2-dfsg.tar.xz > > Surely depending on when something build-depending on gcc-4.5-source is > built, it might be built using gcc-4.5.0-dfsg.tar.xz, but not necessarily > rebuilt with one of the later tarballs? Once gcc-4.5-source_4.5.1-1_all.deb > is uploaded and gcc-4.5-source_4.5.0-10_all.deb disappears from the archive, > it would require a binNMU at least to make sure the depending packages use > the source available in Debian, wouldn't it? > When there are changes affecting gnat / gcj. those maintainers are pinged to reupload package based on updated gcc-4.5-source. Gnat at least uses the usual set of patches from gcc-source package and adds it's own additional patches. >> > The other solution based on Marcin's work, which is also readily >> > supported by the existing -source packages, requires that the target >> > architecture be understood by dpkg (as pointed out by Dmitrijs); that may >> > be a worthwhile goal, notably since it solves the problem of how to >> > provide build packages for the various libraries people find useful, but >> > it's a much longer-term goal as far as I can see... >> >> otoh, this approach breaks more often with updates on patches and >> packaging. Manageable however. > > Yup, as long as the downstream maintainers are on the ball, it should be OK! > The nice thing for you of course is that it means the gcc packaging gets even > more tests. > > Regards, > > Stephen > -- 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/aanlktimjtwveuou8pg_h5xjf9kcax0yywg06oyk=+...@mail.gmail.com
