How to handle JavaScript npm + gulp web GUI packaging?
Hi, I would like to package a web app which contains Javascript stuff, which are using npm + gulp (to disclose everything: I am packaging fuel-web). Currently, the way to build the JavaScript is to do: cd nailgun npm install ./node_modules/.bin/gulp build --static-dir=compressed_static mkdir -p $(CURDIR)/debian/fuel-web-static/usr/share/nailgun cp -r compressed_static \ $(CURDIR)/debian/fuel-web-static/usr/share/nailgun/static cd .. Of course, doing the above in Debian isn't possible, because: 1/ I want to use system nodejs-* and libjs-* packages, not bundle any of these stuff inside my app. 2/ npm does network access to fetch dependencies, which isn't possible at build time So, for the moment, I have written a fuel-web-bundle-js source package containing the non-free pre-built blobs (which typically could be uploaded to non-free), and the fuel-web source package that generates the fuel-web-static that depends on it. I'd like to fix this in a better way so that Fuel can be fully uploaded to Debian main. How to make this all in a Debian policy compliant way? Cheers, Thomas Goirand (zigo) P.S: I'm not afraid of packaging all individual libjs-* and nodejs-* (build-) dependencies, even if there's a big number of them.
Re: How to change config script for multiarch?
At Fri, 12 Feb 2016 01:12:43 +0100,
Jakub Wilk wrote:
> I don't know much about this package, but codesearch.d.n tells me that
> all users of chasen-config call it with the --mkchadic option, which
> causes the script to print /usr/lib//chasen/, which is a
> directory shipped by chasen-config. So it's not completely
> unrelated...
Oh, you are right. And it was already used and dependend in naist-jdic
package. I'll fix it.
> And, as it turns out, the implementation of --mkchadic is the only
> part of the config script that uses the multi-arch triplet in a way
> that can't be trivially patched-out. (The only other place where the
> triplet is used is --libs, where the script prints
> "-L${prefix}/lib/"; but this -L is a no-op that can be
> removed.)
Indeed. I'll remove it.
Re: 50.000 binary packages
On Mon, Feb 8, 2016 at 9:25 PM, Enrico Zini wrote: > On Mon, Feb 08, 2016 at 12:01:41PM +0200, Lars Wirzenius wrote: > >> Possibly someone should set up an online quiz thing, where you're >> shown a package name, its short description, and three randomly chosen >> short descriptions, and have to guess which short description is >> correct. > > plee-the-bear > 2D platform game > program for gridfitting, or "hinting," TrueType fonts > free AdLib sound library (utils) > > (script attached) Should that go here? https://anonscm.debian.org/cgit/collab-maint/debian-fun.git -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to change config script for multiarch?
On Fri, Feb 12, 2016 at 10:20 AM, NOKUBI Takatsugu wrote: > I am also a member of the upstream, but the software is now under > maintainance phase, so it is hard to accept using pkg-config insead of > the current script. > I consider to use pkg-config on debian specific patch in the future. There are non-Debian distributions that are focused on cross-building, I think it would be better if you did the change upstream so that they can cross-build chasen too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to change config script for multiarch?
On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote: > A bit OT: the old-style-config-script lintian description links to a 404 page > on sources.debian.net. Maybe this link should be updated? Is there a way to > create a link to a file on sources.debian.net where, if the version doesn't > exist anymore, it will automatically fall-back to the next highest version? You can use 'latest' or any suite (unstable/testing/etc) or codename (sid/jessie/etc) in the version part of the URL to avoid broken links. Of course if the layout of a source package changes then the link could break, that shouldn't be an issue here though. -- bye, pabs https://wiki.debian.org/PaulWise
Work-needing packages report for Feb 12, 2016
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 710 (new: 3) Total number of packages offered up for adoption: 190 (new: 0) Total number of packages requested help for: 47 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: eyed3 (#813969), orphaned 4 days ago Reverse Depends: burn eyed3 jack pytone Installations reported by Popcon: 2407 python-sockjs-tornado (#813870), orphaned 5 days ago Installations reported by Popcon: 22 yics (#814360), orphaned yesterday Description: Yahoo! Chess client for use with FICS interfaces Installations reported by Popcon: 131 707 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 190 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] samba (#814382), requested today Description: SMB/CIFS file, print, and login server for Unix Reverse Depends: backuppc caja-share cifs-utils ctdb dpsyco-samba freeipa-server freeipa-server-trust-ad fusesmb gadmin-samba gnome-control-center (48 more omitted) Installations reported by Popcon: 134750 athcool (#278442), requested 4125 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 28 awstats (#755797), requested 568 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4180 balsa (#642906), requested 1600 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 709 cardstories (#624100), requested 1753 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 5 cups (#532097), requested 2441 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (66 more omitted) Installations reported by Popcon: 165710 cyrus-sasl2 (#799864), requested 141 days ago Description: authentication abstraction library Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper (126 more omitted) Installations reported by Popcon: 188987 developers-reference (#759995), requested 530 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 18783 devscripts (#800413), requested 135 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (27 more omitted) Installations reported by Popcon: 13042 ejabberd (#767874), requested 465 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml ejabberd-mod-mam-mnesia ejabberd-mod-message-log ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest (4 more omitted) Installations reported by Popcon: 771 fbcat (#565156), requested 2220 days ago Description: framebuffer grabber Installations reported by Popcon: 186 freeipmi (#628062), requested 1722 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: conman freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev (7 more omitted) Installations reported by Popcon: 6370 freerdp (#799759), requested 142 days ago Description: RDP client for Windows Terminal Services (X11 client) Reverse Depends: freerdp-x11 freerdp-x11-dbg libfreerdp-cache1.1 libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0 libfreerdp-core1.1 libfreerdp-crypto1.1 libfreerdp-dbg libfreerdp-dev (28 more omitted) Installations reported by Popcon: 69070 gnat-gps (#496905), requested 2723 days ago Description: co-maintainer needed
Re: How to change config script for multiarch?
* NOKUBI Takatsugu , 2016-02-12, 08:27:
Jakub Wilk wrote:
Are you trying to move the script to libchasen-dev? Why? There are
Debian maintainer scripts that use chasen-config. Are they going to
depend on the -dev package?
Yes, now I will move the script into libchasen-dev because it seems
make sense, chasen-config is not related with chasen dictionaries.
I don't know much about this package, but codesearch.d.n tells me that
all users of chasen-config call it with the --mkchadic option, which
causes the script to print /usr/lib//chasen/, which is a
directory shipped by chasen-config. So it's not completely unrelated...
And, as it turns out, the implementation of --mkchadic is the only part
of the config script that uses the multi-arch triplet in a way that
can't be trivially patched-out. (The only other place where the triplet
is used is --libs, where the script prints "-L${prefix}/lib/";
but this -L is a no-op that can be removed.)
--
Jakub Wilk
Re: How to change config script for multiarch?
At Wed, 10 Feb 2016 13:17:50 +0100, Jakub Wilk wrote: > Are you trying to move the script to libchasen-dev? Why? There are > Debian maintainer scripts that use chasen-config. Are they going to > depend on the -dev package? Yes, now I will move the script into libchasen-dev because it seems make sense, chasen-config is not related with chasen dictionaries.
Re: How to change config script for multiarch?
Thank you your good answer. At Wed, 10 Feb 2016 08:34:10 +0100, Vincent Danjean wrote: > I do not think there is a generic answer. But, if your script is > simple, perhaps just replacing hardcoded directory names by the output > of "dpkg -qDEB_HOST_MULTIARCH" will be enough. I think "dpkg-architecture -qDEB_HOST_MULTIARCH)" is the right command, not dpkg right? > Note that this won't solve cross-compilation issues. For this, unless > specific needs, a convertion to pkg-config style is probably the > easiest/rightest (but it is better to do it with upstream). In this > case, the chasen-config might be rewritten with internal calls to > pkg-config to avoid to duplicate the information and still keeping > the old interface. I am also a member of the upstream, but the software is now under maintainance phase, so it is hard to accept using pkg-config insead of the current script. I consider to use pkg-config on debian specific patch in the future. Thank you again.
Bug#814462: ITP: codecrypt -- Post-quantum encryption and signing tool.
Package: wnpp Severity: wishlist Owner: Mirek Kratochvil * Package name: codecrypt Version : 1.7.3 Upstream Author : Mirek Kratochvil * URL : https://github.com/exaexa/codecrypt * License : LGPLv3 Programming Lang: C++ Description : Post-quantum encryption and signing tool. Codecrypt is a quantum-computer-resistant cryptography tool that can be used to encrypt, decrypt, sign and verify documents and communications in a manner similar to GnuPG or PGP. Several users requested inclusions of the software in Debian; the packages are already available (from ./build-debian-package.sh), working & passing lintian checks.
Re: migrating to Debian gitlab
On Friday 12 February 2016 02:06 AM, Adam Borowski wrote: > On Thu, Feb 11, 2016 at 11:59:09PM +0530, Pirate Praveen wrote: >> Checking /proc/cmdline was working in my test machine as I had systemd >> before it became the default. >> >> I think checking /proc/1/cmdline will be a better method of checking systemd. > > /proc/1/cmdline will be wrong in chroots if the chroot doesn't use systemd > but the host system does. You want to check /run/systemd instead. > Antonio suggested it already in bts and new version uploaded with this change. signature.asc Description: OpenPGP digital signature
Re: migrating to Debian gitlab
On 02/11/2016 09:36 PM, Adam Borowski wrote: > On Thu, Feb 11, 2016 at 11:59:09PM +0530, Pirate Praveen wrote: >> Checking /proc/cmdline was working in my test machine as I had systemd >> before it became the default. >> >> I think checking /proc/1/cmdline will be a better method of checking systemd. > > /proc/1/cmdline will be wrong in chroots if the chroot doesn't use systemd > but the host system does. You want to check /run/systemd instead. Actually, you want to check that /run/systemd/system is a directory, because that is the official way upstream says one should check for PID 1 being systemd, and it is also what sd_booted() from libsystemd0 does, see http://man7.org/linux/man-pages/man3/sd_booted.3.html Regards, Christian signature.asc Description: OpenPGP digital signature
Re: migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)
On Thu, Feb 11, 2016 at 11:59:09PM +0530, Pirate Praveen wrote: > Checking /proc/cmdline was working in my test machine as I had systemd before > it became the default. > > I think checking /proc/1/cmdline will be a better method of checking systemd. /proc/1/cmdline will be wrong in chroots if the chroot doesn't use systemd but the host system does. You want to check /run/systemd instead. -- A tit a day keeps the vet away.
Re: migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)
On 2016, ഫെബ്രുവരി 11 11:18:14 PM IST, Johannes Schauer wrote: >Hi, > >Quoting Pirate Praveen (2016-02-11 16:58:56) >> You can use, >> >> systemctl start gitlab.target >> >> as init script has problems with systemd. The installation is >complete otherwise. >> >> I added systemd unit files already and I will add a check for systemd >to fix the bug. > >thanks, that worked as a temporary workaround! Checking /proc/cmdline was working in my test machine as I had systemd before it became the default. I think checking /proc/1/cmdline will be a better method of checking systemd. >> You'll need to run them as gitlab user and export all variables >defined in /etc/gitlab/gitlab-debian.conf > >thanks, this was *very* valuable knowledge as without it I would >probably be >stuck by now. So I tried this out in practice now and indeed the right >steps to >take seem to be: > >1. Rename your old database to gitlab_production and set the user >gitlab as >its owner and the owner of all its tables, sequences and views > > 2. Copy your old repository directory to /var/lib/gitlab/repositories/ > > 3. Start gitlab using the above systemctl command > > 4. Check its status via: > >$ su gitlab >$ cd >$ export $(cat /etc/gitlab/gitlab-debian.conf | xargs) >$ rake gitlab:check RAILS_ENV=production > >5. The output of above command then will tell you all remaining things >to take >care of, like running: > >$ sudo chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/ > >or > >$ sudo -u gitlab -H /usr/share/gitlab-shell/bin/create-hooks > >or > >$ sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production > >This is extremely helpful! > >Some general notes: > > - it seems to not be necessary to use the "bundle exec" prefix > >- but it is absolutely necessary to be in the home directory of the >gitlab >user (/var/lib/gitlab) as the gitlab user when executing the "rake" >commands > >- exporting the environment variables from >/etc/gitlab/gitlab-debian.conf is > mandatory as well and there'll be error messages without it > >But this was surprisingly painless in the end! My gitlab instance seems >to be >up and running again :) Great! It would be a good idea to document these steps in README.Debian. Can you send a patch? >Thanks! > >cheers, josch -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)
Hi, Quoting Pirate Praveen (2016-02-11 16:58:56) > You can use, > > systemctl start gitlab.target > > as init script has problems with systemd. The installation is complete > otherwise. > > I added systemd unit files already and I will add a check for systemd to fix > the bug. thanks, that worked as a temporary workaround! > You'll need to run them as gitlab user and export all variables defined in > /etc/gitlab/gitlab-debian.conf thanks, this was *very* valuable knowledge as without it I would probably be stuck by now. So I tried this out in practice now and indeed the right steps to take seem to be: 1. Rename your old database to gitlab_production and set the user gitlab as its owner and the owner of all its tables, sequences and views 2. Copy your old repository directory to /var/lib/gitlab/repositories/ 3. Start gitlab using the above systemctl command 4. Check its status via: $ su gitlab $ cd $ export $(cat /etc/gitlab/gitlab-debian.conf | xargs) $ rake gitlab:check RAILS_ENV=production 5. The output of above command then will tell you all remaining things to take care of, like running: $ sudo chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/ or $ sudo -u gitlab -H /usr/share/gitlab-shell/bin/create-hooks or $ sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production This is extremely helpful! Some general notes: - it seems to not be necessary to use the "bundle exec" prefix - but it is absolutely necessary to be in the home directory of the gitlab user (/var/lib/gitlab) as the gitlab user when executing the "rake" commands - exporting the environment variables from /etc/gitlab/gitlab-debian.conf is mandatory as well and there'll be error messages without it But this was surprisingly painless in the end! My gitlab instance seems to be up and running again :) Thanks! cheers, josch signature.asc Description: signature
Re: migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016, ഫെബ്രുവരി 11 8:44:45 PM IST, Johannes Schauer wrote: >Hi, > >Quoting IOhannes m zmölnig (Debian/GNU) (2016-02-11 13:17:36) >> thank you very much for all your efforts! > >let me express my gratitude as well! > >Thank you for all your hard work! It seems installing gitlab pulled in >more >than 330 (!!) ruby packages. You are welcome :) >> now i only need a migration plan :-) > >If you are running systemd, you might want to hold off until RC bugs >#814413 >and #812841 are fixed. You can use, systemctl start gitlab.target as init script has problems with systemd. The installation is complete otherwise. I added systemd unit files already and I will add a check for systemd to fix the bug. >As far as I understand it, migration should be as easy as installing >the new >version over the old version and run: > >rake db:migrate RAILS_ENV=production > >And copy your prior ./repositories directory and authorized_keys file >to their >new location in /var/lib/gitlab. To check your installation one can >use: > >rake gitlab:check RAILS_ENV=production > >Another useful tool seems to be the one to backup the database: > >rake db:migrate RAILS_ENV=production > >The documentation I was able to find prefixes all the above commands >with "sudo >-u gitlab -H bundle exec" but I guess this is not needed anymore with >all >packages installed as Debian packages? You'll need to run them as gitlab user and export all variables defined in /etc/gitlab/gitlab-debian.conf Also better to use bundle exec to make sure bundle is complete (in case some dependencies change). >I'm myself trying to upgrade my version 7.8.4 installation to the >version >currently in Debian but failed because of the RC bugs mentioned above. > >Thanks! > >cheers, josch - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJWBAEBCgBAORxQcmF2ZWVuIEFyaW1icmF0aG9kaXlpbCAocGlyYXRlcGluKSA8 cHJhdmVlbkBkZWJpYW4ub3JnPgUCVryvtgAKCRDOH5xnRRLCKpUUEACMhRRdK3SR fwrQ8rLqH8qkF3nqzgS+2afoFr2YP4oAFZNbOBP+TRbi2BBZvTkJrkDGJIFUhOfX 3i9eq35fUOHXPNrA51IYtMT+Rv1Rt1+94O8K+itcJ3UNYTGPUMAhpUJDb6FM6eA7 siravJwmMdFhXDYDmPkAC2D0FAT2aqz9a6d5ry1dVTz067c0KM42LhJfjK6VR0NZ 4++KsrVjoUnp/rJzKgzE77SW9gvLAFiuP7dWv3Ah9fXagjuv5ggkVW7Pey0NqtCa CrR/OG86xyMZtzfTsxM5MxlaPS0bcaNRTNXGsNjqOuwVpCIE/BQXUfEe9ZUwg4u9 xTWx/1+lromdxEJk2k0Rq00ne8KQUHSTIQAjM4YeCS1Dk2sxRBxyH/DXET71Esxx jzOUQDLTKYzW6I2G1optSHx0hEA4gQceUi08WRW9L3dGcNhkX4cDLbEVVIsaz2ES TFef7Ci1yVnJnO0ogqDY+QzLjkx6fx2mUWmGbSTxetbIQuz383/XacEg3xq3n+GR QkQfU+jMuvnA82dEhp8UHSiJ+Ef7uwzqg5P+TdTV9uZw9pzY2//x0SHHw/0JBBNR fZYL5alw7Tuo36b61YnxR/VTXb+z/Bxm+tdKHHvBA3dVZbgi5WbBN6F53kalAbZR F3eMj908hNARl2W7j4pIMTfph+itokilQw== =l5i+ -END PGP SIGNATURE-
migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)
Hi, Quoting IOhannes m zmölnig (Debian/GNU) (2016-02-11 13:17:36) > thank you very much for all your efforts! let me express my gratitude as well! Thank you for all your hard work! It seems installing gitlab pulled in more than 330 (!!) ruby packages. > now i only need a migration plan :-) If you are running systemd, you might want to hold off until RC bugs #814413 and #812841 are fixed. As far as I understand it, migration should be as easy as installing the new version over the old version and run: rake db:migrate RAILS_ENV=production And copy your prior ./repositories directory and authorized_keys file to their new location in /var/lib/gitlab. To check your installation one can use: rake gitlab:check RAILS_ENV=production Another useful tool seems to be the one to backup the database: rake db:migrate RAILS_ENV=production The documentation I was able to find prefixes all the above commands with "sudo -u gitlab -H bundle exec" but I guess this is not needed anymore with all packages installed as Debian packages? I'm myself trying to upgrade my version 7.8.4 installation to the version currently in Debian but failed because of the RC bugs mentioned above. Thanks! cheers, josch signature.asc Description: signature
Re: GitLab B.V. to host free-software GitLab for Debian project
On 2016-02-10 23:12, Pirate Praveen wrote: > On Friday 22 January 2016 10:20 PM, Balasankar C wrote: >> On വ്യാഴം 21 ജനുവരി 2016 07:11 വൈകു, Pirate Praveen wrote: >>> I need help with integrating debconf for configuring hostname. Somehow I'm >>> not able to troubleshoot the error. It seems I'm missing something simple, >>> I tried to follow debconf tutorial and compare many times, but only to see >>> a cryptic error message. >>> >>> https://gitlab.com/debian-ruby/TaskTracker/issues/41 >> >> This issue has been fixed. Two echo statements (for verbosity) used >> before loading confmodule caused the issue. Removed them and debconf is >> no longer an issue. >> >> > > Now gitlab in unstable is rc bug free and can migrate to testing (if we thank you very much for all your efforts! now i only need a migration plan :-) fgmasdr IOhannes
Bug#814418: ITP: python-shotgun -- Create and save Fuel diagnostic snapshots
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-shotgun Version : 0.1.0~0+2016.12.30.git.0682f20c42 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/shotgun * License : Apache-2.0 Programming Lang: Python Description : Create and save Fuel diagnostic snapshots Fuel is an open source deployment and management tool for OpenStack. Developed as an OpenStack community effort, it provides an intuitive, GUI-driven experience for deployment and management of OpenStack, related community projects and plug-ins. . Fuel brings consumer-grade simplicity to streamline and accelerate the otherwise time-consuming, often complex, and error-prone process of deploying, testing and maintaining various configuration flavors of OpenStack at scale. Unlike other platform-specific deployment or management utilities, Fuel is an upstream OpenStack project that focuses on automating the deployment and testing of OpenStack and a range of third-party options, so it’s not compromised by hard bundling or vendor lock-in. . Shotgun takes a yaml files with command lines as argument so that it can collect log files and such to help diagnose problems in Fuel.
Re: How to change config script for multiarch?
Hi, Quoting Jakub Wilk (2016-02-11 12:44:34) > * Johannes Schauer , 2016-02-10, 11:09: > >The old-style-config-script tag which src:chasen suffers from as well and > >which was also linked to by Bastien contains more valuable information. The > >important message is: please use pkg-config and not some package-specific > >configuration mechanism (as also already pointed out by Vincent). Otherwise, > >you (and/or upstream) will suffer from an unnecessary maintenance burden in > >case you ever want to (or in case we need to) cross-build that source > >package. For now though it should be sufficient to move the file into an > >architecture specific path. > > Um, no. Replacing an upstream-supported API, which has existing users > even in the Debian archive, with a Debian-specific non-upstreamable one > sounds like a very bad plan to me. please excuse my bad phrasing of my last message. When I said "please use pkg-config" then I didn't mean "please do X without consulting and collaborating with upstream". Indeed it would be best if you could convince upstream to switch to pkg-config and not make the change Debian specific unless there is more pressing need for doing so. Thanks! cheers, josch signature.asc Description: signature
Re: How to change config script for multiarch?
* Johannes Schauer , 2016-02-10, 11:09: I am a maintainer of chasen package. It contains chasen-config, it work as pkg-config like but it's a single script. Latest lintain reports: E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config full text contains architecture specific dir x86_64-linux-gnu But I want to keep libchasen-dev as Multi-Arch: same. Would you tell me finding the correct way to change the script? [...] The old-style-config-script tag which src:chasen suffers from as well and which was also linked to by Bastien contains more valuable information. The important message is: please use pkg-config and not some package-specific configuration mechanism (as also already pointed out by Vincent). Otherwise, you (and/or upstream) will suffer from an unnecessary maintenance burden in case you ever want to (or in case we need to) cross-build that source package. For now though it should be sufficient to move the file into an architecture specific path. Um, no. Replacing an upstream-supported API, which has existing users even in the Debian archive, with a Debian-specific non-upstreamable one sounds like a very bad plan to me. -- Jakub Wilk
Bug#814407: ITP: fuel-web -- OpenStack Fuel deployment server & web GUI
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: fuel-web Version : 9.0~0+2016.02.11.git.0a3a744bd5+dfsg1 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/fuel-web * License : Apache-2.0, Expat Programming Lang: Python, Ruby, Javascript Description : OpenStack Fuel deployment server & web GUI Fuel is an open source deployment and management tool for OpenStack. Developed as an OpenStack community effort, it provides an intuitive, GUI-driven experience for deployment and management of OpenStack, related community projects and plug-ins. . Fuel brings consumer-grade simplicity to streamline and accelerate the otherwise time-consuming, often complex, and error-prone process of deploying, testing and maintaining various configuration flavors of OpenStack at scale. Unlike other platform-specific deployment or management utilities, Fuel is an upstream OpenStack project that focuses on automating the deployment and testing of OpenStack and a range of third-party options, so it’s not compromised by hard bundling or vendor lock-in. . Nailgun is the core part of a Fuel master node server. It consists of a REST API server (nailgun-api), and a web interface (nailgun-web).
Bug#814402: ITP: apertium-sme-nob -- Apertium translation data for the Northern Sami-Norwegian Bokmål pair
Package: wnpp
Severity: wishlist
Owner: Kartik Mistry
* Package name: apertium-sme-nob
Version : 0.6.0~r65146
Upstream Author : Francis Tyers, Kevin Brubeck Unhammer, Trond Trosterud
* URL : http://apertium.org/
* License : GPL-2+
Programming Lang:
Description : Apertium translation data for the Northern Sami-Norwegian
Bokmål pair
Data package providing Apertium language resources for translating
between the Northern Sami and Norwegian Bokmål languages.
- why is this package useful/relevant? is it a dependency for
another package? do you use it? if there are other packages
providing similar functionality, how does it compare?
A: Apertium translation data for the Northern Sami-Norwegian Bokmål
pair.
- how do you plan to maintain it? inside a packaging team
(check list at https://wiki.debian.org/Teams)? are you
looking for co-maintainers? do you need a sponsor?
A: Under debian-science + Apertium maintainers.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
signature.asc
Description: PGP signature
Bug#814400: ITP: giella-sme -- Giellatekno single language data for North Saami
Package: wnpp
Severity: wishlist
Owner: Kartik Mistry
* Package name: giella-sme
Version : 0.0.20150917~r129253
Upstream Author : Giellatekno at The University of Tromsø
* URL : http://giellatekno.uit.no/
* License : GPL-2+
Programming Lang:
Description : Giellatekno single language data for North Saami
Data package providing Giellatekno language resources for North Saami
- why is this package useful/relevant? is it a dependency for
another package? do you use it? if there are other packages
providing similar functionality, how does it compare?
A: Dependency of apertium-sme-nob
- how do you plan to maintain it? inside a packaging team
(check list at https://wiki.debian.org/Teams)? are you
looking for co-maintainers? do you need a sponsor?
A: Under debian-science + Apertium maintainers.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
signature.asc
Description: PGP signature
Bug#814398: ITP: giella-core -- GTCORE files for building Giellatekno language
Package: wnpp
Severity: wishlist
Owner: Kartik Mistry
* Package name: giella-core
Version : 0.1.1~r129227
Upstream Author : Giellatekno at The University of Tromsø
* URL : http://giellatekno.uit.no/
* License : GPL-2+
Programming Lang:
Description : GTCORE files for building Giellatekno language packages
(Include the long description here.)
- why is this package useful/relevant? is it a dependency for
another package? do you use it? if there are other packages
providing similar functionality, how does it compare?
A: Dependency of giella-sme, apertium-sme-nob
- how do you plan to maintain it? inside a packaging team
(check list at https://wiki.debian.org/Teams)? are you
looking for co-maintainers? do you need a sponsor?
A: Inside debian-science umbrealla + Apertium maintainers.
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
signature.asc
Description: PGP signature
