Re: New #packaging IRC channel
Marc Haber writes: > Not having been on #debian-mentors for a long time, what is the > problem with helping people building local packages there, having the > chance of giving them skills that can be of use in Debian proper at a > later time? Since you haven't been on the channel for a long time, what is your objection to creating a ‘#packaging’ channel to take the not-for-Debian packaging chatter? -- \ “Unix is an operating system, OS/2 is half an operating system, | `\Windows is a shell, and DOS is a boot partition virus.” —Peter | _o__)H. Coffin | Ben Finney
Re: New #packaging IRC channel
Paul Wise writes: > On Sat, Sep 3, 2016 at 7:12 PM, Vincent Bernat wrote: > > > Why not #debian-packaging? > > It is unrelated to Debian so includes no debian- prefix. More to the point, the ‘debian-’ prefix implies that it is specifically for the Debian Project. As I understand it, the purpose of the ‘#packaging’ channel is to avoid that constraint: unlike a channel whose name is ‘deb-’ or ‘debian-’ prefixed, any OFTC-appropriate packaging discussion is appropriate there. -- \ “Liberal capitalism is not at all the Good of humanity. Quite | `\the contrary; it is the vehicle of savage, destructive | _o__) nihilism.” —Alain Badiou | Ben Finney
Re: Built-Using:
* Paul Wise , 2016-09-04, 09:46: As I understand Policy, Built-Using: should mention any packages, parts of which were incorporated into binary package, including any debhelper, that insert shell snippets into maintainer scripts, flex/bison. There is some controversy about Built-Using, some say it is only for packages that embed code/data that is under copyleft licenses like the GNU GPL, not for everything. Other folks would like to use it for more things, such as static linking. Either way, putting debhelper in B-U just because it generated maintainer scripts would be something novel. Which debhelper is used to create this field The field is created manually, you can see some examples here: https://codesearch.debian.net/search?q=Built-Using Yes, and this is rather cumbersome. :-\ Related dpkg build: #689062 Also, dh_buildinfo is superseded by .buildinfo files from the reproducible builds effort s/is/will be/ -- Jakub Wilk
Re: New #packaging IRC channel
> what is the problem with helping people building local packages > there, having the chance of giving them skills that can be of use > in Debian proper at a later time? 100% with this remark. I've been starting to package .deb a few months ago for a linux audio based-on-debian (basicaly an external repo) and I've been asking question a few time things at #debian-mentor. Those questions, and more over, their answers have been helping me learning some of the ropes of the debian packaging that I didn't find and/or understand when reading the maint guide or other online ressources. This allowed me to start working *properly* on a packaging which is expected to get in debian official repo when done. If I would have been flicked on an common-ground #packaging channel which *obviously* will not have the same level of competences that #mentors have, I wouldn't have certainly be able to learn efficiently deb-packaging things. For my case, it would have been a loss. Let's says as well that I'm using my external repo to test stuff and I'm reporting oftenly improvements to packages to the BTS. So the "barrier" between "what is debian, and what is not debian" appears to be vague here. Enjoying this communication to say thanks to the people who have been helping me on #mentors in answering my questions and pointing me in the right direction when it was needed. Olivier
Bug#836381: RFS: couchapp/1.0.2+dfsg1-1
Gianfranco I didn't forget about this, I'm in the middle of a peak of work, I'll get it done in the next few days. thanks! -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa signature.asc Description: PGP signature
Re: New #packaging IRC channel
humbert.olivie...@free.fr writes: > If I would have been flicked on an common-ground #packaging channel > which *obviously* will not have the same level of competences that > #mentors have What basis do you have for that claim? There are many people already on IRC who have demonstrated a sustained willingness to help with not-for-Debian packaging work. The ‘#packaging’ channel is a forum where that is welcome. So that seems to be solid evidence that a lot of people are already available to join ‘#packaging’ with the expertise you describe. Indeed, the demonstrated willingness of many such people is, I think, one reason the channel was created. -- \ “We have met the enemy and he is us.” —Walt Kelly, _Pogo_ | `\1971-04-22 | _o__) | Ben Finney
Re: New #packaging IRC channel
On Sun, Sep 04, 2016 at 05:40:12PM +1000, Ben Finney wrote: > Marc Haber writes: > > Not having been on #debian-mentors for a long time, what is the > > problem with helping people building local packages there, having the > > chance of giving them skills that can be of use in Debian proper at a > > later time? > > Since you haven't been on the channel for a long time, what is your > objection to creating a ‘#packaging’ channel to take the not-for-Debian > packaging chatter? I have been cutting down on my IRC presence. If I were still on #mentors, I would most probably not burden myself with just another IRC channel. Greetings Marc, who should actually unsubscribe from the -mentors mailing list as well -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: New #packaging IRC channel
* Ben Finney , 2016-09-04, 17:40: Marc Haber writes: Not having been on #debian-mentors for a long time, what is the problem with helping people building local packages there, having the chance of giving them skills that can be of use in Debian proper at a later time? Since you haven't been on the channel for a long time, what is your objection to creating a ‘#packaging’ channel to take the not-for-Debian packaging chatter? I didn't read what Mark wrote as an objection, but as an honest inquiry. I'm curious to know others' opinions, too. -- Jakub Wilk
d/control: Depends on same version
hi mentors, if i have source package foo-x.y that builds binary packages foo_x.y and libfoo_x.y, how can i declare a dependency from foo on libfoo where libfoo has to be the same version of foo? thanks and cheers, -- muri signature.asc Description: OpenPGP digital signature
Bug#836701: RFS: nlohmann-json/2.0.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "nlohmann-json" * Package name: nlohmann-json Version : 2.0.3-1 Upstream Author : Niels Lohmann * URL : https://github.com/nlohmann/json * License : MIT Section : libs It builds those binary packages: nlohmann-json-dev - JSON for Modern C++ To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nlohmann-json Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nlohmann-json/nlohmann-json_2.0.3-1.dsc More information about hello can be obtained from https://nlohmann.github.io/json/. Changes since the last upload: * New upstream release cheers, -- muri signature.asc Description: OpenPGP digital signature
Re: d/control: Depends on same version
On 09/04/2016 09:40 PM, Muri Nicanor wrote:
> if i have source package foo-x.y that builds binary packages foo_x.y and
> libfoo_x.y, how can i declare a dependency from foo on libfoo where
> libfoo has to be the same version of foo?
If both are Arch: any (or linux-any or something similar):
Depends: libfoo (= ${binary:Version})
However, if one of the packages is Arch: all, and if you want to be
binNMU-friendly, you should probably rather use something like
Depends: libfoo (>= ${binary:Version}), libfoo (<< ${binary:Version}+b+~)
(Don't use it for the case where both are Arch: any though.)
Regards,
Christian
Bug#836709: RFS: 9wm/1.3.9-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "9wm" * Package name: 9wm Version : 1.3.9-1 Upstream Author : Jacob Adams * URL : https://github.com/9wm/9wm/ * License : Expat Section : x11 It builds those binary packages: 9wm - X11 window manager inspired by Plan 9's rio To access further information about this package, please visit the following URL: https://mentors.debian.net/package/9wm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/9/9wm/9wm_1.3.9-1.dsc Changes since the last upload: 9wm (1.3.9-1) unstable; urgency=medium * New upstream release * Fix manpage typo (Closes: #836314) -- Jacob Adams Sun, 04 Sep 2016 21:48:37 -0400 Regards, Jacob Adams
qbs building (with qt)
qbs is yat-another build system. From the QT people. Allegedly it is quite sensible (according to someone familiar with Make, qmake, and cmake). I am trying to package something that uses it. Is anyone familiar with this in debian-world? Especially with respect to selected qt4 or qt5? Some docs are here: http://doc.qt.io/qbs/configuring.html with some info on selecting qt versions here: http://doc.qt.io/qbs/qt-versions.html A typical build seems to look something like this: qbs-setup-toolchains --detect qbs-setup-qt /usr/bin/qmake default qbs build -f .qbs profile:default except you actually need to add qbs config profiles.default.baseProfile gcc (if both gcc and clang are installed, because the toolchain --detect stage finds both.) The problem with this is that it detects qt4, and thus fails to build a qt5 project. using the alternative qbs-setup-qt --detect also chooses qt4 if it is installed. (i.e generates a profile called 'qt-4-8-7') qbs expects you to be able to point at a different binary path for qmake(qt4 version) and qmake (qt5 version). But in debian qmake seems to be a wrapper from the qtchooser package. I can't see a way to say 'default to qt5 for anything that asks'. I've not yet followed all the details of how qbs-setup-qt does its selection, and maybe there is some debian rune for default-setting that I have missed. Perhaps what is actually needed is for the debian packaging of qbs to work together with qtchooser to DTRT? It doesn't seem to be possible to install just qt5, as installing it pulls in qt4. And having both installed is quite likely to be needed in various circumstances, so we need to make it possible to get qbs to use the right one. OK, doing QT_SELECT=5 qbs-setup-qt /usr/bin/qmake default generates a 'default' profile which points at qt5. Is the recommended way to do it? QT_SELECT=5 qbs-setup-qt --detect makes two profiles: 'qt-5-6-1' and 'qt-4-8-7' (not just the qt5 one for some reason) I can then use qbs build -f .qbs profile:qt-5-6-1 to build with the right stuff, but this is not much use for putting in a rules file because that profile name is going to change every time qt is updated. Also builds leave a directory called -debug in the source directory after builds. Is there a standard way to get qbs to tidy up after itself, or does the rules file have to do that. (rm -rf *-debug works so long as there is nothing already called that in the sources...) Anyway, clues very welcome from anyone familiar with this stuff. I'll carry on prodding in the meantime to try and grok it all. OK. I got it to build eventually, but it may not be optimal as described above. My rules file looks like this. Assuming this is about right, I guess it would be good to teach debhelper and dh_make about qbs. %: dh $@ override_dh_auto_configure: qbs-setup-toolchains --detect QT_SELECT=5 qbs-setup-qt /usr/bin/qmake default # choose gcc as if clang is installed too you have to pick one qbs config profiles.default.baseProfile gcc override_dh_auto_build: qbs build -f dewalls.qbs profile:default override_dh_clean: # tidy up qbs profile builddirs qbs clean profile:default rm -r *-debug dh_clean Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: New #packaging IRC channel
On Sun, Sep 04, 2016 at 09:21:21PM +0200, Jakub Wilk wrote: > * Ben Finney , 2016-09-04, 17:40: > >Marc Haber writes: > >>Not having been on #debian-mentors for a long time, what is the problem > >>with helping people building local packages there, having the chance of > >>giving them skills that can be of use in Debian proper at a later time? > > > >Since you haven't been on the channel for a long time, what is your > >objection to creating a ‘#packaging’ channel to take the not-for-Debian > >packaging chatter? > > I didn't read what Mark wrote as an objection, but as an honest inquiry. Yes, that was my intention. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
