Bug#1074793: ITP: git-ubuntu -- maintain an Ubuntu source package in a git tree
Package: wnpp Severity: wishlist Owner: Benjamin Drung X-Debbugs-Cc: debian-devel@lists.debian.org, bdr...@debian.org * Package name: git-ubuntu Version : 1.1 Upstream Contact: ubuntu-devel-disc...@lists.ubuntu.com * URL : https://launchpad.net/git-ubuntu * License : GPL-3 Programming Lang: Python Description : maintain an Ubuntu source package in a git tree git-ubuntu is tooling that provides unified git-based workflows for the development of Ubuntu source packages. . The git-ubuntu importer service maintains a view of the entire packaging version history of Ubuntu source packages using git repositories with a common branching and tagging scheme. The git-ubuntu CLI provides tooling and automation that understands these repositories to make the development of Ubuntu itself easier. . Since Ubuntu's packaging architecture pre-dates git, different packages have evolved to use different mechanisms to achieve the same thing. Developers had to learn them all in order to be effective when working across a wide range of packages. git-ubuntu's unification of these mechanisms allows for simpler, more general tooling, which results in faster onboarding of new developers and easier "drive-by" contributions. . git-ubuntu is useful for those inspecting, working on, or looking to contribute to Ubuntu source packages themselves. I am using this package and plan to maintain it as part of the Debian Python Team. -- Benjamin Drung Debian & Ubuntu Developer
Bug#542106: ITP: promoe -- gui client for xmms2
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: promoe Version : 0.1 Upstream Author : Thomas Frauendorfer * URL : http://wiki.xmms2.xmms.se/wiki/Client:Promoe * License : GPL v2 Programming Lang: C++ Description : gui client for xmms2 Promoe is a client for the xmms2 music daemon. Promoe’s interface is modeled after XMMS/WinAMP classic. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
Am Donnerstag, den 10.09.2009, 16:09 +0200 schrieb Sandro Tosi: > Ideally, I'd imaging nnn...@b.d.o to reach > > - submitter > - maintainers > - subscribers > > We already have -quite if we want to not mail people. > > Do others feel we should enable emailing the submitter by default? Yes, please email the submitter by default. It would be good if the submitter can unsubscribe himself from the bug report. Cheers, Benjamin signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: DEP-5: an example parser, choice of syntax for Files:
Am Sonntag, den 13.09.2009, 23:58 +0100 schrieb Jon Dowland: > Most of the examples given in DEP-5 containing the path > character will not work, either, e.g. > > Files: debian/* > > Assuming they are passed into a find(1) invocation like so > > find . -path 'debian/*' > > (note the presence of the path separator and the wording > about that in the text) > > they need to be prefixed with './', even if you omit '.' in > the find execution (which itself is a GNUism iirc). Patch > attached. You can get rid of those './' by replacing . with *: find * -path 'debian/*' Cheers, Benjamin signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Hi, When a new upstream version is released, I have to check all patches if they were accepted by upstream or not. I have to check each patch if I can drop it. It would make packaging new releases easier if there were an optional Applied-Upstream field. Every patch that was applied upstream can be dropped. "no" or "not-yet" would indicate that the patch was not applied yet. If the patch was applied, it could contain the revision (like "r4681") or a link to the VCS commit. What do you think about my suggestion? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Montag, den 23.11.2009, 08:42 +0100 schrieb Raphael Hertzog: > Hi, > > On Mon, 23 Nov 2009, Benjamin Drung wrote: > > When a new upstream version is released, I have to check all patches if > > they were accepted by upstream or not. I have to check each patch if I > > can drop it. It would make packaging new releases easier if there were > > an optional Applied-Upstream field. Every patch that was applied > > upstream can be dropped. "no" or "not-yet" would indicate that the patch > > was not applied yet. If the patch was applied, it could contain the > > revision (like "r4681") or a link to the VCS commit. > > > > What do you think about my suggestion? > > I suppose that you would want to add the field as soon as the patch is > committed upstream so that you can more easily identify patches to remove > when the next upstream version is out? Yes, indeed. > Do you expect to automate this operation? Adding the field would be manual, but removing the patches can do a simple script, when the next upstream release is out. > I'm not sure we need a new field for this purpose, you could add a comment > in the description field or even change the Forwarded: URL to point to the > upstream VCS to make it clearer that it got merged. Automating the removal would be hard then. > BTW, speaking of DEP-3, someone mentioned that it doesn't tell the > encoding to use. Does anyone oppose to adding a note saying that it > should aim at being ASCII-only and if that's not possible then UTF-8 > should be used? I think that the DEP-3 header should be in UTF-8 (ASCII would be the subset). -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Montag, den 23.11.2009, 09:18 +0100 schrieb Goswin von Brederlow: > Benjamin Drung writes: > > > Hi, > > > > When a new upstream version is released, I have to check all patches if > > they were accepted by upstream or not. I have to check each patch if I > > can drop it. It would make packaging new releases easier if there were > > an optional Applied-Upstream field. Every patch that was applied > > upstream can be dropped. "no" or "not-yet" would indicate that the patch > > was not applied yet. If the patch was applied, it could contain the > > revision (like "r4681") or a link to the VCS commit. > > > > What do you think about my suggestion? > > Why would the source (or VCS head) ever contain a patch that was > applied upstream? The moment the patch gets applied you simply remove > it. Not until the next upstream release. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
How to use binutils-gold
Hi, I got some FTBFS with binutils-gold bug reports. How can I build my packages using binutils-gold? What do I have to change for that? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#559761: ITP: release -- provides information about the current releases
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: release Version : 0.1 (native) Upstream Author : Benjamin Drung * License : GPL v3+ Programming Lang: Python Description : provides information about the current releases This package contains information about all releases of Debian and Ubuntu. The release script will give you the codename for e.g. the latest stable release of your distribution. To get information about a specific distribution there are the debian-release and the ubuntu-release scripts. It's based on the idea posted on the ubuntu-devel-discuss mailing list [1]. Comments, suggestions and feature requests are highly welcome. For Debian I need some informations: Until when were following releases supported: buzz, rex, bo, hamm, slink, and potato? [1] http://www.mail-archive.com/ubuntu-devel-disc...@lists.ubuntu.com/msg09951.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
Am Dienstag, den 08.12.2009, 16:56 +0100 schrieb Thomas Koch:
> Hi,
>
> I'm triing to package a little java library, which contains its own .jar and
> some pregenerated docs. These files should be regenerated on build time. So
> I'd like to have them removed by diff.gz
> Trying to generate an appropriate quilt patch failed. The only thing I came
> up
> with, was a patch that contains the whole content of the removed files with -
> before every line.
> Anybody more clever then me?
>
> I know that dpatch allows the execution of shell scripts. This would be
> ideal.
> I'd just do find . -name "*.jar" -exec rm {} \;
>
> But also a patch which contains just the names of the files to be removed and
> not the whole content would suffice.
Putting 'find . -name "*.jar" -delete' in you clean rule should do the
same job for you.
--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT:
> On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
> >
> > * Package name: release
>
> The tool isn't about releasing, but about to querying the release. Also,
> it's about distribution release (not package...). May be a name like
> {get|query}-distr[o]?-release... or something completely different like
> "supported-distro" would be more explicit.
Yes, the name is a bit to generic. Any other suggestions for the name?
On the mailing list I found 'release-info'. On my list are now:
* release-info
* distro-release-info
* distro-releases
Any preferred name or suggestions?
Should i rename the scripts, too?
> > Description : provides information about the current releases
> >
> > This package contains information about all releases of Debian and Ubuntu.
> > The
> > release script will give you the codename for e.g. the latest stable
> > release of
> > your distribution.
>
> There was some discussions about a similar tool & issues:
> http://lists.debian.org/debian-devel/2007/05/msg01138.html
> and to query Debian point release.
> http://lists.debian.org/debian-devel/2007/12/msg00742.html
The topic of these discussions were slightly different. The release
packages does not know anything about the running release. It only needs
a date (and up-to-date data) for calculating the result.
> > To get information about a specific distribution there are
> > the debian-release and the ubuntu-release scripts.
>
> I suppose you mean that there will be different back-end script.
> (I suppose that you don't mean that each program will have to implement
> a select/case algorithm?)
Yes, there are different back-end scripts. Due to different release
models the both scripts use different algorithms. The distro data are
stored in cvs files (like a table) and then I throw a little bit of
Python on it. Subtracting the command line parsing only 60 lines of code
are required.
> > It's based on the idea posted on the ubuntu-devel-discuss mailing list
> > [1]. Comments, suggestions and feature requests are highly welcome.
> >
> > For Debian I need some informations: Until when were following
> > releases supported: buzz, rex, bo, hamm, slink, and potato?
>
> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
> information for bo/rex/buzz. Anyone ?
I found that page, too. The wikipedia page of Debian did not contain
more information.
> AFAIK, Debian have never supported more than two stable distributions
> (stable + old-stable), therefore, you can assume that a distribution end
> of life is "lower than" distribution N+2 release.
I used this algorithm to calculate the support dates until we find
something more precise.
--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Mittwoch, den 09.12.2009, 09:34 +0800 schrieb Paul Wise: > On Wed, Dec 9, 2009 at 8:07 AM, Benjamin Drung wrote: > > Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT: > >> On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote: > >> > For Debian I need some informations: Until when were following > >> > releases supported: buzz, rex, bo, hamm, slink, and potato? > >> > >> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the > >> information for bo/rex/buzz. Anyone ? > > > > I found that page, too. The wikipedia page of Debian did not contain > > more information. > > Try the debian-history package or its maintainer. I could not find information about the support period in this package. Bdale, do you have more information? Am Mittwoch, den 09.12.2009, 15:05 +0100 schrieb Javier Fernandez-Sanguino: > The proper source for this information is the Project History > document, available online at > http://www.debian.org/doc/manuals/project-history/ch-releases.en.html > or in the debian-history package. I could not find end of live dates on this website. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
To sum up the naming discussion, there are two possible package names: * distro-release-info * release-info The two distro-specific script will be named debian-release-info and ubuntu-release-info. I tend to name the package distro-release-info and the symlinked script release-info. Any preferences, suggestions, or objections? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Freitag, den 11.12.2009, 09:17 +0100 schrieb Frank Lin PIAT: > On Fri, 2009-12-11 at 00:09 +0100, Benjamin Drung wrote: > > To sum up the naming discussion, there are two possible package names: > > > > * distro-release-info > > * release-info > > > > The two distro-specific script will be named debian-release-info and > > ubuntu-release-info. I tend to name the package distro-release-info and > > the symlinked script release-info. > > The distro specific script should be in /usr/share/release-info/. No. If I want to know the current stable release of Debian, I have to run 'debian-release-info -s' regardless which os/distro I run. > If the distribution specific scripts are in the path, people may tend to > use them, which isn't portable because one needs to know the local > distribution before invoking the script. It depends on the purpose. Portable scripts have to use release-info, but distribution specific scripts can use $distro-release-info. > Also, it you be nice if your script was easily extensible by Debian and > Ubuntu derivatives. Every derivative can add their own $distro-release-info script. Having one generic script for all distributions would not work, because there is not _one_ release policy for all. > BTW, did you notice that the DebianRelease[1] wiki page has a link per > distribution release, with EOL dates (?) Yes, but for buzz to hamm (1.1 to 2.0) the EOL dates are missing. > I just have a feature request: add some "--foobar-url" options, which > would return some official urls about that distribution: > * Info and support (http://www.debian.org/releases/lenny/ ) > * Release Notes (http://www.debian.org/releases/lenny/releasenotes ) > * Errata (http://www.debian.org/releases/stable/errata ) > * Installation Guide (http://www.debian.org/releases/lenny/installmanual ) Do you have a use case for that? If you want to know these URLs for the current installed distro, you can use lsb_release instead: http://www.debian.org/releases/$(lsb_release -cs)/ http://www.debian.org/releases/$(lsb_release -cs)/releasenotes We would need the equivalent URLs for Ubuntu. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#559761: ITP: release -- provides information about the current releases
Am Freitag, den 11.12.2009, 15:57 -0600 schrieb Peter Samuelson: > [Benjamin Drung] > > Yes, the name is a bit to generic. Any other suggestions for the name? > > On the mailing list I found 'release-info'. On my list are now: > > > > * release-info > > * distro-release-info > > * distro-releases > > I'd go with 'os-release'. Mostly because I hate the word 'distro'. To avoid the distro/os discussion, I will use release-info as package name. It's short and not too generic. > Unix tradition is to have a bit of OS release info in one flag of > 'uname' or another, but of course on Linux, where the kernel and the > userland are fairly decoupled, this makes less sense. > > (Also, one might think /usr/share/misc/config.guess could say whether > we're on debian or ubuntu ... but it doesn't.) -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#562217: ITP: jdownloader -- download manager for one-click hosting sites
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: jdownloader Version : 0.1 Upstream Author : JDownloader DEV-Team * URL : http://jdownloader.org/ * License : GPL-3 Programming Lang: Java Description : download manager for one-click hosting sites JDownloader is open source, platform independent and written completely in Java. It simplifies downloading files from One-Click-Hosters like Rapidshare.com or Megaupload.com - not only for users with a premium account but also for users who don't pay. It offers downloading in multiple paralell streams, captcha recognition, automatical file extraction and much more. Of course, JDownloader is absolutely free of charge. Additionally, many "link encryption" sites are supported - so you just paste the "encrypted" links and JD does the rest. JDownloader can import CCF, RSDF and the new DLC files. . This package contains only a dektop file and a script, which will download and launch the current JDownloader. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
Am Sonntag, den 10.01.2010, 14:30 +0100 schrieb Xavier Roche: > Hi folks, > > How to deal with a desktop-command-not-in-package lintian warning when a > .desktop file in a "common" package B references a binary in package A ? > > Typically the package A used to contain static/arch-independent data > which was splitted to a B "common" package to comply with debian > packaging rules (to limit the size of architecture-dependent packages). > > Solution 1: consider the warning a false positive and ignore it > Solution 2: pull back the destop command in the arch-dependent package Solution 2 is the correct answer. > (I can not reverse the dependencies, because A _do_ depends on data in B.) First I thought it would be a strange warning, but then I understood it. Imagine that you install only the data package B, which contains the desktop file. Then you have a desktop icon, but you cannot launch the application. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bits from the Mozilla Extension Packaging Team
Hi, This mail targets all developers, which maintain Mozilla extensions. Source package name === The source package name for extension should not contain the name of the enhanced application. These prefixes should be dropped from the source name: firefox- iceape- icedove- iceweasel- mozilla- thunderbird- If the remaining string is too generic (for example, notify or sage), the source package name should append -extension. For example, firefoxnotify was renamed to notify-extension. Binary package name === The Mozilla extension packaging team decided to use xul-ext- (instead of mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1]. This will group the extensions visually. There are currently 18 extensions that use this naming scheme already. Please rename the binary package if not already done. Use mozilla-devscripts == To make packaging extensions dead simple we have mozilla-devscripts. In most cases debian/rules can be reduces to three or four lines (shebang, two includes and maybe one variable). We highly recommend using it. An additional benefit of using mozilla-devscripts is that derived distribution can use the source code without modifying it. mozilla-devscripts take care of the distributions specialities. The usage is explained in the Wiki [2]. Joining our team You are welcome to join our team. We maintain all packages in git in the pkg-mozext group. You can contact us via email or IRC [3]. Please let us know, if you need help implementing the above mentioned items. Work needing package Here is a list of source package that need to updated. Please let me know, if I missed some packages. beagle biofox ctxextensions diggler firegpg foxyproxy icedove-attachmentreminder icedove-gcontactsync icedove-quotecolors iceweasel-downthemall imagezoom livehttpheaders mozilla-dom-inspector mozilla-noscript mozvoikko nostalgy nukeimage vimperator [1] http://wiki.debian.org/Mozilla/ExtensionsPolicy [2] http://wiki.debian.org/mozilla-devscripts [3] http://wiki.debian.org/Teams/DebianMozExtTeam -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bits from the Mozilla Extension Packaging Team
Am Montag, den 01.02.2010, 21:34 +0100 schrieb Thilo Six: > Question 1: > You propose to use the prefix "xul-ext-" which is more generic i guess but > the itself is called "pkg-mozext". > Is that "moz" in the team name for historic reasons? Yes, it's only for historic reasons. > Or is it planed to rename it "pkg-xul-ext" Team? There is currently no plans to rename the team, but it's worth thinking about it. What do the other team member think about it? > 2nd question: > In the good old days (when ever these were) someone like a short sighted > person like me could search via apt or aptitude for *compatible* extentions > to his application. > Now does it mean, that all those xulrunner based apps can make use the same > extensions? > e.g. does ist make sens to use "xul-ext-quotecolors" with iceweasle? The extension must support the xulrunner based apps. quotecolors will support the same amount of xulrunner based apps after the rename. According to upstream it does not work with iceweasel. > Realy i don't get so please explain a bit more deeply. When using mozilla-devscripts, the extension will enhance the supported xulrunner apps and provide xulapt-extname. In the case of xul-ext-quotecolors, it will enhance icedove and provide icedove-quotecolors. So are still able to run "apt-get install icedove-quotecolors" or "apt-get install iceweasel-adblock-plus". -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bits from the Mozilla Extension Packaging Team
Am Montag, den 01.02.2010, 15:48 -0500 schrieb James Vega: > On Mon, Feb 1, 2010 at 3:34 PM, Thilo Six wrote: > > Benjamin Drung wrote the following on 01.02.2010 20:34 > >> icedove-quotecolors > > > > 2nd question: > > In the good old days (when ever these were) someone like a short sighted > > person like me could search via apt or aptitude for *compatible* extentions > > to his application. > > Now does it mean, that all those xulrunner based apps can make use the same > > extensions? > > e.g. does ist make sens to use "xul-ext-quotecolors" with iceweasle? > > It does make sense to use xul-ext-quotecolors with iceape, even though > the current package forces icedove usage. With mozilla-devscripts, the package would recommend "icedove | iceape" on Debian (and "thunderbird | seamonkey" on Ubuntu). So you wouldn't be forced to install icedove. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Pkg-mozext-maintainers] Bits from the Mozilla Extension Packaging Team
2010/2/2 Mike Hommey : > On Mon, Feb 01, 2010 at 08:34:31PM +0100, Benjamin Drung wrote: >> Hi, >> >> This mail targets all developers, which maintain Mozilla extensions. >> >> Source package name >> === >> >> The source package name for extension should not contain the name of the >> enhanced application. These prefixes should be dropped from the source >> name: >> >> firefox- >> iceape- >> icedove- >> iceweasel- >> mozilla- >> thunderbird- >> >> If the remaining string is too generic (for example, notify or sage), >> the source package name should append -extension. For example, >> firefoxnotify was renamed to notify-extension. > > I don't remember this has been discussed, and i certainly disagree with > this naming scheme. Also, existing extensions sources shouldn't be renamed. Yes, we only discussed binary names. The same rules apply for source package names. Why should Debian have a source package with firefox in its name (for example, firefox-notify) and why should Ubuntu have a source package with icedove in its name (for example, icedove-quotecolors)? This would be similar to the python name scheme. For example the source package matplotlib provides the binary package python-matplotlib. >> Binary package name >> === >> >> The Mozilla extension packaging team decided to use xul-ext- (instead of >> mozilla-, iceweasel-, etc.) as prefix for all Mozilla extensions [1]. >> This will group the extensions visually. There are currently 18 >> extensions that use this naming scheme already. Please rename the binary >> package if not already done. > > Note the policy proposal has not been updated with the latest > propositions (for which i was hoping more feedback, btw). See the team > list archives. I read the archives. There are still some parts of the policy proposal that needs more discussion (for example the directory question). The binary naming part was discussed and we reached the consensus that using xul-ext- as prefix is the lesser of the two evils, didn't we? >> Use mozilla-devscripts >> == >> >> To make packaging extensions dead simple we have mozilla-devscripts. In >> most cases debian/rules can be reduces to three or four lines (shebang, >> two includes and maybe one variable). We highly recommend using it. An >> additional benefit of using mozilla-devscripts is that derived >> distribution can use the source code without modifying it. >> mozilla-devscripts take care of the distributions specialities. The >> usage is explained in the Wiki [2]. >> >> Joining our team >> >> >> You are welcome to join our team. We maintain all packages in git in the >> pkg-mozext group. You can contact us via email or IRC [3]. Please let us >> know, if you need help implementing the above mentioned items. >> >> Work needing package >> >> >> Here is a list of source package that need to updated. Please let me >> know, if I missed some packages. > > I have a lintian check that checks most of the policy, except it was > written before lintian 2.3 and doesn't work anymore. If someone has the > time to update the script before me, I'll send it to them. What will be checked by that? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Dienstag, den 02.02.2010, 21:32 + schrieb brian m. carlson: > On Tue, Feb 02, 2010 at 07:59:04PM +0100, Fabian Greffrath wrote: > > while we are at it, maybe we could take the opportunity and introduce a > > similar scheme for all packages providing mozilla-compatible browser > > plugins as well? > > I hope you mean NPAPI[0] plugins, since those will work on non-Gecko > browsers. In general, there's few good reasons to have plugins that > work only on Gecko browsers, especially since that means that a large > number of browsers that Debian supports (such as Konqueror and > Webkit-based browsers like Epiphany) are left without useful plugins. > > > I remember this discussion has been here before. My favourite approach > > these days was to suffix all packages with -browserplugin, because that > > perfectly describes what the package contains, but is a little bit too > > long, maybe. Given the current approach, I think some prefix like > > xul-plugin- would fit better and feel more consistent with the naming > > scheme of the extensions packages. What do you think? > > I think xul-plugin- is only okay if it will only work on Gecko-based > browsers. It is inaccurate and misleading to use xul-plugin- unless the > plugin is designed to do something specifically with Gecko. I would > suggest npapi- as a prefix for plugins that use that interface. I would > suggest that plugins that do not use that interface adopt it forthwith. > :-) npapi- prefix is not very user friendly. It reminds me of the PCMCIA card. xul-plugin- sounds better, but do not fit. The least evil proposal was to append -browserplugin. Better suggestions are welcome. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Donnerstag, den 04.02.2010, 10:13 +0100 schrieb Fabian Greffrath: > Am 03.02.2010 07:14, schrieb Mike Hommey: > > I'd go for the -browserplugin suffix. > > Fine, but what now? Can we already call this a consensus? Shall I file > wishlist bugs against the affected packages? What's the opinion of the > affected packages' maintainers? We should gather more opinions, especially from the affected packages' maintainers. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: About new source formats for packages without patches
Am Donnerstag, den 25.03.2010, 16:16 + schrieb Philipp Kern: > On 2010-03-25, Josselin Mouette wrote: > > I’d expect it to be much smoother for an organization that uses Debian > > tools and works with us to add missing functionality in them if needed, > > than for an organization that uses its own tools. > > You seriously don't want to force dak upon everyone. And there is not > even a package. (And the same is true for wanna-build, sadly.) Why is there no dak and wanna-build package? Are there plans to create such packages? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: About new source formats for packages without patches
Am Donnerstag, den 25.03.2010, 17:57 +0100 schrieb Julien BLACHE: > Benjamin Drung wrote: > > Hi, > > > Why is there no dak and wanna-build package? Are there plans to create > > such packages? > > Have you ever tried to install dak? No. > If you have, then the answer should be obvious to you. If you haven't, > try it someday, and you'll understand. Reading your response, I probably want to spend my year doing something else like coding or packaging. Is there a plan for making the installation of dak easier? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled
Am Donnerstag, den 25.03.2010, 23:30 +0100 schrieb Joerg Jaspert: > Additionally we have one package in the archive that we can not help > with a binnmu, a full source upload is required. The maintainer got a > seperate mail asking for the upload, but for reference, its fatsort, the > latest version. That explains why fatsort is gone. Thanks for the info. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
Am Mittwoch, den 31.03.2010, 15:45 +0200 schrieb Mehdi Dogguy: > Julian Andres Klode wrote: > > On Wed, Mar 31, 2010 at 03:13:14PM +0200, Mehdi Dogguy wrote: > >> Paul Wise wrote: > >>> On Wed, Mar 31, 2010 at 1:03 AM, Julian Andres Klode > >>> wrote: > >>> > >>>>> Description : debhelper add-on to call autoreconf and clean up > >>>>> after the build > >>>>> > >>>>> Package: dh-autoreconf > >>> I'd suggest just putting this into debhelper rather than making it a > >>> separate package. > >>> > >> Is there any advantage to have it packaged? > >> > >> AIUI, you have to add a build-dependency anyway and change at least one > >> line in the debian/rules to call dh-autoreconf. Well, that line could > >> simply call autoreconf (or whatever) which even makes debian/rules clearer. > > > > The difference is that dh_autoreconf calls autoreconf and stores a list > > of the changes and the changed files are then removed in the clean > > target. If you just call autoreconf, the changes end up in the diff; > > and this is not what we want. > > > > I do use autoreconf and I don't have these changes in my diff. > > IMO, a backup/restore script (where you specify the list of files to > backup) may be more useful. It would be called before build and when cleaning. I prefer the removal over the restoring the old files. You remove .o files on clean, so why not remove the other auto-generated files on clean? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Applied-Upstream field for Patch Tagging Guidelines (DEP-3)
Am Freitag, den 16.04.2010, 22:48 +0200 schrieb Raphael Hertzog: > Hi, > > sorry for the delay answering. > > On Mon, 29 Mar 2010, Colin Watson wrote: > > I don't know that we need to bother with two fields, though. There's > > precedent in DEP-3 for fields with internal structure; the format of > > Origin is not dissimilar to what we need here. How about something like > > the following? > > Thanks for the suggestion, it looks good so I applied it. Thanks. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Sonntag, den 25.04.2010, 13:26 +0200 schrieb Yves-Alexis Perez: > On jeu., 2010-02-04 at 17:21 +0100, Yves-Alexis Perez wrote: > > On 03/02/2010 07:14, Mike Hommey wrote: > > > I'd go for the -browserplugin suffix. > > > > > > Speaking of plugins, I see there are several plugin packages that put > > > plugins in various places. Here is a breaking news: the canonical place > > > for plugins is /usr/lib/mozilla/plugins. Nowhere else. > > > > > > Why ? Because it's where most of the plugins already are (but some > > > packages like to put their files in several places, which is pointless), > > > and it's where all applications are already looking for plugins. > > > > > I started packaging parole media player which provides a plugin using > > npapi, and recently submitted a bug to split rhythmbox package. In both > > case I used the scheme: > > > > browser-plugin-* > > > > (replacing mozilla by browser, in fact). None of the packages are > > already uploaded so I can still change. > > I'm about to upload parole, so I'd like to know what's the status on > this? At the moment a search on -browserplugin doesn't return anything. > A search on browser-plugin returns cairo-dock-quick-browser-plugin and > that's all. It seems that no package was really renamed. > > What should we do? I think we should start using the new naming policy to add the -browserplugin suffix. There were some votes for -browserplugin and none against it. No better name was proposed. Therefore I think that it was decided. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Sonntag, den 25.04.2010, 23:51 +0200 schrieb Yves-Alexis Perez: > On dim., 2010-04-25 at 18:58 +0200, Benjamin Drung wrote: > > > What should we do? > > > > I think we should start using the new naming policy to add the > > -browserplugin suffix. > > > > There were some votes for -browserplugin and none against it. No > > better > > name was proposed. Therefore I think that it was decided. > > To be perfectly fair, browser-plugin-* had my vote, but anyway. We didn't discussed browser-plugin-*. Should we make a poll with *-browserplugin and browser-plugin-*? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Montag, den 26.04.2010, 11:07 +0200 schrieb Stefano Zacchiroli: > On Mon, Apr 26, 2010 at 10:39:39AM +0200, Jean-Christophe Dubacq wrote: > > > I'd rather say that generally binary packages split words at '-', so if > > > you've a choice among these two the latter is preferable. > > > > If this is so, then browserplugin-* should content everyone. > > I'm sure you meant "browser-plugin-*" here ... Hm, browserplugin-* would be a new option. Then we would have 1. browser-plugin-* 2. browserplugin-* 3. *-browserplugin 4. *-browser-plugin I think all of these would work (with a slight preference to 1. or 2.). Opinions? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Montag, den 26.04.2010, 18:49 +0200 schrieb Stefano Zacchiroli: > On Mon, Apr 26, 2010 at 04:56:15PM +0200, Benjamin Drung wrote: > > > I'm sure you meant "browser-plugin-*" here ... > > Hm, browserplugin-* would be a new option. Then we would have > > > > 1. browser-plugin-* > > 2. browserplugin-* > > 3. *-browserplugin > > 4. *-browser-plugin > > > > I think all of these would work (with a slight preference to 1. or 2.). > > Opinions? > > Please don't do polls on a mailing list :-) > > Arguments have been given for using '-' in the name (while I haven't > seen any argument for _not_ using dashes). I presume the general feeling > about whether it should be at the beginning or at the end of packages is > "we don't particularly care", as long as it is consistent. > > I personally don't think a poll is needed, but if you feel it is please > set up one somewhere and post just a participation link. I setup a doodle poll: http://www.doodle.com/2wmykvgy7ara5pd5 Please participate there. And yes, doodle is designed for schedules, but not for polls. ;) -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Montag, den 26.04.2010, 20:40 +0200 schrieb Benjamin Drung: > Am Montag, den 26.04.2010, 18:49 +0200 schrieb Stefano Zacchiroli: > > On Mon, Apr 26, 2010 at 04:56:15PM +0200, Benjamin Drung wrote: > > > > I'm sure you meant "browser-plugin-*" here ... > > > Hm, browserplugin-* would be a new option. Then we would have > > > > > > 1. browser-plugin-* > > > 2. browserplugin-* > > > 3. *-browserplugin > > > 4. *-browser-plugin > > > > > > I think all of these would work (with a slight preference to 1. or 2.). > > > Opinions? > > > > Please don't do polls on a mailing list :-) > > > > Arguments have been given for using '-' in the name (while I haven't > > seen any argument for _not_ using dashes). I presume the general feeling > > about whether it should be at the beginning or at the end of packages is > > "we don't particularly care", as long as it is consistent. > > > > I personally don't think a poll is needed, but if you feel it is please > > set up one somewhere and post just a participation link. > > I setup a doodle poll: http://www.doodle.com/2wmykvgy7ara5pd5 > > Please participate there. And yes, doodle is designed for schedules, but > not for polls. ;) I create a new poll that allows yes/no/maybe: http://www.doodle.com/guafbbhipwskzr8a Please add yourself there. Sorry for the inconvenience. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins
Am Montag, den 26.04.2010, 23:58 +0200 schrieb Goswin von Brederlow: > "Hans-J. Ullrich" writes: > > > Am Montag, 26. April 2010 schrieb Goswin von Brederlow: > >> Benjamin Drung writes: > >> > Am Montag, den 26.04.2010, 11:07 +0200 schrieb Stefano Zacchiroli: > >> >> On Mon, Apr 26, 2010 at 10:39:39AM +0200, Jean-Christophe Dubacq wrote: > >> >> > > I'd rather say that generally binary packages split words at '-', so > >> >> > > if you've a choice among these two the latter is preferable. > >> >> > > >> >> > If this is so, then browserplugin-* should content everyone. > >> >> > >> >> I'm sure you meant "browser-plugin-*" here ... > >> > > >> > Hm, browserplugin-* would be a new option. Then we would have > >> > > >> > 1. browser-plugin-* > >> > 2. browserplugin-* > >> > 3. *-browserplugin > >> > 4. *-browser-plugin > >> > > >> > I think all of these would work (with a slight preference to 1. or 2.). > >> > > >> > Opinions? > >> > >> I think *-bwoser[-]plugin is a bad choice for 2 reasons (which you can > >> consider one reason): > >> > >> A) apt-get install browser > >> > >> This will complete nicely to give me a list of plugins with options 1 > >> and 2 and all the packages it completes have a common use case, to make > >> my browser better. No such thing with options 3 and 4. > >> > >> B) Sorting in frontends (aptitude, ...) > >> > >> Again say you are looking for usefull plugins to add to your > >> browser. With options 1 and 2 you get all the plugins in one blog and > >> can easily scroll through them. With options 3 and 4 they will be > >> scattered all over the place. > >> > >> > >> I think the seperate groups formed by a common prefix in options 3 and 4 > >> would be much smaller and less usefull to users than having all browser > >> plugins in one block. > >> > >> MfG Goswin > >> > > > > I think, 3 and 4 are the better choices than 1 or 2. IMO, the best choice > > might be 4. Let me just explain why: > > > > If people are looikng for something, they first look, what application it > > is in > > for. Browser plugins might be available for iceweasel, konqueror, opera > > whatever. So, the first choice is "iceweasel-", then what is it? Yes, it is > > for > > the "-browser", and at last, they see, yes, a "-plugin". > > > > I also imagine, that in the future, there might be > > iceweasel-"sound"-plugins, > > "video"-plugins, "flash"-plugins or whatever. I also imagine, there might > > be > > also not only plugins, but "tools", or maybe "modules". > > By that reasoning you are advocating: > > 5. browser-*-plugin > > That would also work for apt-get install browser Ok, I added it to the poll, but i doubt that it will win against browser-plugin-*. > > IMO we should decide for a structure or syntax, that is easy to understand > > and > > modular for future changes -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [OT] Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Am Dienstag, den 27.04.2010, 10:02 +0900 schrieb Charles Plessy: > Le Mon, Apr 26, 2010 at 08:40:41PM +0200, Benjamin Drung a écrit : > > > > I setup a doodle poll > > Dear Benjamin, > > I would like to recommend http://selectricity.org/ instead. In contrary to > Doodle, Selectricity is free software. Thanks, I bookmarked it and will use it the next time. It is free software (indicated by "Copyleft"), but I haven't found the source code. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Architecture Nomenclature
Am Dienstag, den 27.04.2010, 12:45 -0700 schrieb Kip Warner: > Greetings Everyone, > > I've been looking for a while, but no luck. Is there a table somewhere > that summarizes the different architecture names like i386, i586, i686, > amd64, ia64, and so on along with the criteria for hardware qualifying > under that name? I am not aware of a table. I would search for the names and see which is the first architecture and check their features. > e.g. Does i686 mandate SSE2? i686 = Pentium Pro and later = only MMX amd64 mandates SSE2 (and therefore MMX and SSE) > PS I am not on the mailing list, so please remember to cc me. Thanks. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Architecture Nomenclature
Am Dienstag, den 27.04.2010, 14:45 -0700 schrieb Kip Warner: > On Tue, 2010-04-27 at 21:43 +0100, Ben Hutchings wrote: > > It must be 'i386'. > > But i386 includes machines like the 486 and the Pentium Pro that did not > have SSE2 instruction set. > > If I was writing something for a 32-bit machine with SSE2 instruction > set, what would be the most appropriate architecture name? The best solution would be autodetection of SSE2 on runtime. That can be done with a few lines of code. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Binary package names for mozilla plugins [Was: Bits from the Mozilla Extension Packaging Team]
Hi, after some days the poll [1] has been a clear result. browser-plugin-* has won with a huge winning margin. [1] http://www.doodle.com/guafbbhipwskzr8a -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: The number of popcon.debian.org-submissions is falling
Am Donnerstag, den 22.07.2010, 10:20 +0200 schrieb Yves-Alexis Perez: > On 21/07/2010 10:25, Paul Wise wrote: > > They also currently have almost 20 times as many popcon submissions as > > Debian and continuing growth: > > > > http://popcon.ubuntu.com/ > > http://popcon.ubuntu.com/stat/sub-i386.png > > Is it enabled by default without asking the user? (I didn't do an ubuntu > install since warty or hoary so I wouldn't know) No. You have to enable it in a submenu. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: How to make Debian more attractive for users
Am Donnerstag, den 22.07.2010, 23:14 +0800 schrieb Paul Wise: > On Thu, Jul 22, 2010 at 4:28 PM, Giacomo A. Catenazzi wrote: > > > I think it is bugous to ask such question. > > > > IMHO we should care about improving Debian, going toward the perfection, not > > about increasing the number of users (which should > > be a nice secondary effect). > > > > I don't think increasing the number of Debian user is per se > > a nice things, after looking Ubuntu. > ... > > So, let see how to improve Debian, not how to increase > > our userbase! > > The two are not entirely unrelated. I was a user of Debian before I > was a Debian contributor. All developers come from a pool of users and > with more developers we can make a better distro. Figuring out how to > convert users into developers is the hard part though. Debian contributors don't have to be Debian users at the beginning. They can come from Debian-derived distributions and contribute directly to Debian to avoid work duplication. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: The number of popcon.debian.org-submissions is falling
Am Montag, den 26.07.2010, 10:30 +0200 schrieb Raphael Hertzog: > Hi, > > On Thu, 22 Jul 2010, Benjamin Drung wrote: > > Am Donnerstag, den 22.07.2010, 10:20 +0200 schrieb Yves-Alexis Perez: > > > On 21/07/2010 10:25, Paul Wise wrote: > > > > They also currently have almost 20 times as many popcon submissions as > > > > Debian and continuing growth: > > > > > > > > http://popcon.ubuntu.com/ > > > > http://popcon.ubuntu.com/stat/sub-i386.png > > > > > > Is it enabled by default without asking the user? (I didn't do an ubuntu > > > install since warty or hoary so I wouldn't know) > > > > No. You have to enable it in a submenu. > > I could not find that "submenu" while installing 10.04. It's quite > possibly only in the alternate installer image nowadays (that is used > for the server edition AFAIK). On the last step (7 of 7), there is the "Advanced..." button. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: The number of popcon.debian.org-submissions is falling
Am Freitag, den 30.07.2010, 14:24 +0200 schrieb Raphael Hertzog: > On Fri, 30 Jul 2010, Benjamin Drung wrote: > > > I could not find that "submenu" while installing 10.04. It's quite > > > possibly only in the alternate installer image nowadays (that is used > > > for the server edition AFAIK). > > > > On the last step (7 of 7), there is the "Advanced..." button. > > Yes, and there's nothing about popcon there. There's stuff for grub and > a Network proxy IIRC: > http://i1-news.softpedia-static.com/images/extra/LINUX/large/ubuntu1004installation-large_008.jpg > > OTOH Karmic seems to have the checkbox: > http://i1-news.softpedia-static.com/images/extra/LINUX/large/ubuntu910installation-large_010.jpg Ok, then it was dropped. software-properties-gtk has an easy way to enable popcon. In Ubuntu there is a description what popcon does and what it is used for, but software-properties-gtk in squeeze doesn't have it. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Search for a file in all Debian source packages
Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke: > Hi, > > I want to determine in what Debian _source_ packages a file with a > particular name exists. There used to be a webservice that had all? > source packages indexed and allowed for this type of query, but I cannot > remember what it was -- maybe it doesn't exist anymore. http://www.debian.org/distrib/packages There you can search the contents of packages. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: This is a digitally signed message part
Re: Search for a file in all Debian source packages
Am Donnerstag, den 30.09.2010, 14:38 -0400 schrieb Michael Hanke: > On Thu, Sep 30, 2010 at 08:33:54PM +0200, Benjamin Drung wrote: > > Am Donnerstag, den 30.09.2010, 14:31 -0400 schrieb Michael Hanke: > > > Hi, > > > > > > I want to determine in what Debian _source_ packages a file with a > > > particular name exists. There used to be a webservice that had all? > > > source packages indexed and allowed for this type of query, but I cannot > > > remember what it was -- maybe it doesn't exist anymore. > > > > http://www.debian.org/distrib/packages > > > > There you can search the contents of packages. > > _Binary_ packages. This is not what I was looking for. Oops. IIRC there was a website where you can search the source code, but this website took the code directly from upstream. So this might not fit your needs. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: This is a digitally signed message part
Re: Create package for XUL-based app
Am Montag, den 18.10.2010, 17:26 -0500 schrieb David Rios: > Hi. > > I want to package a XUL-based application which isn't in Debian > Repository yet. I've read many tutorials, including "Debian New > Maintainters' Guide" but I can't find how to package this kind of apps. > You don't have to compile it (it's an script-based app) so it doesn't > have a "Makefile" file. I use "dpkg-buildpackage" and it creates a .deb > file but it doesn't include my app. Can you help me? where can I find > instructions? You probably want to use mozilla-devscripts to package it. Look at the wiki page [1] and look how other XUL extensions (e.g. adblock-plus) are packaged. [1] http://wiki.debian.org/mozilla-devscripts -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: This is a digitally signed message part
Bug#602977: ITP: ocs -- Opal Compilation System
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: ocs Version : 2.3n Upstream Author : Opal Group, TU Berlin * URL : https://projects.uebb.tu-berlin.de/opal/ * License : GPL, LGPL (will probably change) Programming Lang: C, Opal Description : Opal Compilation System The Opal project is concerned with research into a programming environment in which advanced language concepts and formal development methods can be used for creating production-quality software. At the core of the project is the algebraic programming language, Opal, which integrates both concepts of algebraic specification and functional programming. A comprehensive set of tools supporting the language constitutes the Opal compilation system OCS. I am in direct contact with the upstream maintainer to get the package suitable for Debian (relicensing documentation under DFSG compliant license, FHS compliance, lintian fixes). We target to have a new upstream version at the end of the year and to get this into the archive. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101109235654.12865.15671.report...@localhost6.localdomain6
Bug#608496: ITP: libkibi -- library for byte prefixes
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: libkibi Version : 0.1 Upstream Author : Benjamin Drung * URL : https://launchpad.net/libkibi * License : ISC Programming Lang: C Description : library for byte prefixes This library is designed for formatting bytes. The byte prefixes are used depending on the user preferences. Three different types of byte prefixes can be selected: * kB, MB, GB with base 1000 (base10) * KiB, MiB, GiB with base 1024 (base2) * KB, MB, GB with base 1024 (historic) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101231131726.11708.56346.report...@localhost6.localdomain6
Re: DEP5: CANDIDATE and ready for use in squeeze+1
Am Sonntag, den 09.01.2011, 14:27 + schrieb Lars Wirzenius: > On su, 2011-01-09 at 15:18 +0100, Jakub Wilk wrote: > > * Lars Wirzenius , 2011-01-09, 14:00: > > > [3] http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?rev=153&sc=0 > > > > > >If you are interested, please give the spec a quick read. If you find > > >any real problems, it is not too late to get them fixed. > > > > Let me see: > > > > | Example: > > | > > | Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 > > | Upstream-Name: SOFTware > > | Upstream-Contact: John Doe > > | Source: http://www.example.com/software/project > > > > r135 is quite an old version (and, in fact, this snippet doesn't even > > follow the r135 syntax). > > Oh, right. I haven't updated those Format: examples, yet, since there is > no good URL to update them to. Updating to specific revisions in SVN is > bad. Once the spec is incorporated into the debian-policy package, we > can have a nice stable URL, which will change whenever the spec changes. > > But I guess I could change the rev=135 url to rev=153 for now, to avoid > confusion. change to rev=154 (which will be the revision with the fixed revision). ;) I am playing with the idea to write python script (using python-debian) which parses debian/copyright and do some useful stuff. For example wrap-and-sort could format it nicely. Having some glue code for software-center would be nice. Third idea is to write a checker tool that compares debian/copyright with the file headers (licensecheck output). The Files field contains a space separated files list. What to do if the file name contains a space? How should this space escaped? -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Bug#613306: ITP: portsmf -- Portable Standard Midi File Library
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: portsmf Version : 0.1~svn20101010 Upstream Author : Roger B. Dannenberg * URL : http://portmedia.sourceforge.net/ * License : Expat Programming Lang: C++ Description : Portable Standard Midi File Library Portsmf is "Port Standard MIDI File", a cross-platform, C++ library for reading and writing Standard MIDI Files. . Features: . - input and output of Standard MIDI Files - data structures, classes, etc. for representing music data in memory o sequence structure consisting of multiple tracks o track structure consisting of multiple events o events contain note and control data o extensible attribute-value property lists o tempo track and time signature representation - input and output of a text-based representation: Allegro files - extensive editing operations on sequences and tracks - conversion to/from binary buffers for archiving, undo/redo, etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110213230656.1077.21059.reportbug@localhost6.localdomain6
Bug#613517: ITP: libsbsms -- Subband Sinusoidal Modeling Synthesis
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: libsbsms Version : 1.7.0 Upstream Author : Clayton Otey * URL : http://sbsms.sourceforge.net/ * License : GPL2 Programming Lang: C++ Description : Subband Sinusoidal Modeling Synthesis libsbsms is a C++ library for high quality time stretching and pitch scaling of audio. It uses octave subband sinusoidal modeling. The audio is fed into a FIFO, which takes the STFT of the input. Each frame is high-pass filtered in the Fourier domain, and then written to a frame FIFO which does quadratic interpolating peak detection and track continuation. The tracks are resynthesized with a quadratic phase preserving oscillator bank at an arbitrary time scale. The subbands are fed from the low-pass filtered frames, which are decimated by two and reconstructed in a half rate time domain. The subbands perform the same process as the parent band, only the data is at half the audio frequency, and at half the rate. There are typically 6 bands. The point of subbands is to allow high time resolution for high frequencies and at the same time high frequency resolution for low frequencies. Pitch scaling is performed in a post-processing resampling step. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215124525.5084.47114.reportbug@localhost6.localdomain6
Re: What should we do with iceweasel/xulrunner/libmozjs?
Am Freitag, den 18.02.2011, 10:12 +0100 schrieb Mike Hommey: > Hi, > > Now that squeeze is released, it's time to start pushing new things to > unstable. I've been asked several times already how things would be > evolving in the near future, to which I answered it would quite stay the > way it is now until upstream releases 4.0, at which point I'd upload 4.0 > to unstable. But that might change. And I'm hereby requesting feedback > on what fellow developers (especially maintainers of the various reverse > dependencies) think about them. > > Here are some of the available options: > > - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push > 4.0 to unstable when it's out. > Pros: More exposure for the 3.6 and 4.0 packages. > Cons: More work for reverse dependencies, which would be made to build > and work with 3.6 and then again with 4.0 in a few weeks. > Last time I checked (which was 3 months ago), 4.0 doesn't work > on s390, sparc and ia64, which would make problems. > > - Keep things the way they are (3.5 in unstable, 3.6 in experimental, > 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's > released. > Pros: we don't need to make sure everything in unstable builds and > works properly with 3.6 before doing the work again with 4.0 in a > month or so. > Cons: Broken architectures with 4.0. > > - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental > when it's released. > Pros: We don't break anything in testing/unstable, and we don't have > to deal immediately with the broken architectures. > Cons: We lose version 3.6, which has several advantages over 3.5, and > keep 3.5, which is already very outdated. > > - Keep everything in place, prepare rdeps to build and work with 4.0, > and push 4.0 to unstable when everything is ready. > Pros: We don't break anything in testing/unstable, and when 4.0 lands > on unstable, nothing breaks either. > Cons: Past experience shows that it takes a lot of time to fix rdeps. > My gut feeling is that breaking things in unstable would create an > incentive to fix, which doesn't exist when the package is in > experimental or worse, outside the archive. > > - Suggest your own if you have better ideas (really, I mean it). > > As I mentioned above, my initial idea was to go with the second option, > breaking most rdeps in the process, but then I remembered that 4.0 > doesn't work on all our architectures, and I'm hesitating, now. > > So, fellow developers, what do you think? I favor a combination of idea one and two, which is: Keep 3.5 in unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Then we have one big break and a tested 4.0 in unstable. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Upcoming changes in Lintian & some bits
Am Donnerstag, den 24.02.2011, 08:16 +0100 schrieb Yves-Alexis Perez: > On Wed, 2011-02-23 at 22:47 -0600, Raphael Geissert wrote: > > As a consequence of these changes, the new Lintian release will cause > > many existing overrides to no longer apply. We recognise that this will > > lead to some noise in the short term but are convinced that the longer > > term advantages make this worthwhile. > > > Did you do an archive check with the new lintian and diff'ed it against > a check with previous lintian? Please do a complete archive check on lintian.debian.org. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
new scripts and patches for devscripts
Hi, I have two topics I like to discuss: 1. ubuntu-dev-tools contains a bunch of scripts. Some of them are useful only for Ubuntu, but some of them are general usable for packaging. These scripts are: add-patch check-symbols cowbuilder-dist debian-distro-info distro-info edit-patch get-build-deps merge-changelog mk-sbuild pbuilder-dist pull-debian-source (?) reverse-build-depends suspicious-source what-patch wrap-and-sort Should these script moved from ubuntu-dev-tools into devscripts? Most of the script are written in Python. Rewriting them to get them included in devscripts is too much work without benefit. devscripts would depend on python then. 2. devscripts appears to me not very well maintained. It has 11 uploaders, but 237 bugs are open. In contrast ubuntu-dev-tools, which has a similar count of scripts, has only around 50 open bugs. The more astonishing number is the 45 patches waiting to be reviewed. What can be done to improve this number? -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: > On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: > > 1. ubuntu-dev-tools contains a bunch of scripts. Some of them are useful > > only for Ubuntu, but some of them are general usable for packaging. > > These scripts are: > > > > mk-sbuild > > Speaking just for this script, it's a "user-friendly" wrapper around > sbuild/schroot to do initial setup, including package installation and > chroot creation. However, it's very Ubuntu-specific. Rather than > copy the script, even with the Ubuntu-specifics taken out, I'd rather > integrate select pieces into sbuild proper such as into > sbuild-createchroot. > > If the other scripts are of a similar nature, I don't think they are > suitable with significant modification; it may be worth looking at > correcting the deficiencies in the tools they wrap. Maybe one or two. For example suspicious-source and wrap-and-sort are good candidates for devscripts. > > Should these script moved from ubuntu-dev-tools into devscripts? > > > > Most of the script are written in Python. Rewriting them to get them > > included in devscripts is too much work without benefit. devscripts > > would depend on python then. > > Most of the scripts are short. Rewriting would be fairly simple, and > may be beneficial in removing the Ubuntu-specific bits. What speaks against having these script in python? Is python too heavy for a _development_ machine? -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 16:42 + schrieb Ian Jackson:
> Benjamin Drung writes ("new scripts and patches for devscripts"):
> > 1. ubuntu-dev-tools contains a bunch of scripts. Some of them are useful
> > only for Ubuntu, but some of them are general usable for packaging.
> > These scripts are:
> >
> > add-patch
> > check-symbols
> > cowbuilder-dist
> > debian-distro-info
> > distro-info
> > edit-patch
> > get-build-deps
> > merge-changelog
> > mk-sbuild
> > pbuilder-dist
> > pull-debian-source (?)
> > reverse-build-depends
> > suspicious-source
> > what-patch
> > wrap-and-sort
>
> Almost all of these are very poorly named.
Better name suggestions are welcome.
--
Benjamin Drung
Debian & Ubuntu Developer
signature.asc
Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega: > On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung wrote: > > Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: > >> On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: > >> > Should these script moved from ubuntu-dev-tools into devscripts? > >> > > >> > Most of the script are written in Python. Rewriting them to get them > >> > included in devscripts is too much work without benefit. devscripts > >> > would depend on python then. > >> > >> Most of the scripts are short. Rewriting would be fairly simple, and > >> may be beneficial in removing the Ubuntu-specific bits. > > > > What speaks against having these script in python? Is python too heavy > > for a _development_ machine? > > It's not just about a package dependency. It's more about restricting > the knowledge base required for those maintaining the package. > > Considering that scripts are contributed to devscripts and the support > burden is then commonly left on the shoulders of those maintaining > devscripts instead of the original script author, it's in our interest > to maintain a consistent set of languages that we are willing to > support. This is currently Perl and shell. > > So yes, IMO, accepting scripts written in Python (or any other language) > is too heavy. Not for a "_development_ machine", but for a maintenance > team. If people choose to ignore our requirement and develop scripts in > other languages, then they can deal with the consequences. Stefano Rivera (stefanor) and I offer to maintain the Python scripts in devscripts. Is it enough to have at two DDs to support Python? -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Mittwoch, den 09.03.2011, 22:28 + schrieb Ian Jackson:
> Benjamin Drung writes ("Re: new scripts and patches for devscripts"):
> > Am Mittwoch, den 09.03.2011, 16:42 + schrieb Ian Jackson:
> > > > add-patch
> > > > check-symbols
> > > > cowbuilder-dist
> > > > debian-distro-info
> > > > distro-info
> > > > edit-patch
> > > > get-build-deps
> > > > merge-changelog
> > > > mk-sbuild
> > > > pbuilder-dist
> > > > pull-debian-source (?)
> > > > reverse-build-depends
> > > > suspicious-source
> > > > what-patch
> > > > wrap-and-sort
> > >
> > > Almost all of these are very poorly named.
> >
> > Better name suggestions are welcome.
>
> udt-* for all applicable *, where "udt" stands for "ubuntu-dev-tools".
Why? These scripts are not ubuntu specific. Would you rename all scripts
in devscripts for "dv-*", where "dv" stands for devscripts?
--
Benjamin Drung
Debian & Ubuntu Developer
signature.asc
Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Freitag, den 11.03.2011, 00:18 +0100 schrieb Stefano Zacchiroli: > On Thu, Mar 10, 2011 at 08:15:22PM +0100, Carsten Hey wrote: > > James Vega seems to be the most active devscripts maintainer these days, > > and he does this (as far as I know) in his spare time. If he does not > > want to have python scripts in it, I see no justification to force him > > to do so. I also see no reason to try hard to convince him after he > > clearly stated his point of view. > > First of all, I'm not sure anymore that I see the point of discussing > the *language issue* in a circle larger than the devscripts maintainers. > (Disclaimer: although I'm still listed as devscripts uploader, I > consider myself in violation of that rule as wall: it's been quite a > while since my last significant contribution to the package.) The > language issue should probably be a decision within the devscripts team, > together with the script proposers. Can we continue to discuss the language issue on debian-devel or should we move the discussion somewhere else? -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Donnerstag, den 10.03.2011, 14:34 -0500 schrieb James Vega: > On Thu, Mar 10, 2011 at 12:48 PM, Stefano Zacchiroli wrote: > > Also, considering we are talking about Python and not, say, my beloved > > OCaml, I wouldn't be surprised to discover that among active Debian > > developers we have nowadays more Python knowledge than Perl knowledge > > (but I'm already regretting starting this potential troll ...). Back to > > numbers, according to [1] already in Debian 4.0 the number of SLOC in > > the archive of Python vs Perl was very close (2.5% vs 2.8%) with a > > strong growing trend for Python. > > > > To conclude with an obvious argument, rewriting useful tools which are > > known to work and which are currently maintained by a derived distro, > > when they are already written in a popular language, doesn't seem to be > > the smartest thing to do to me. > > I completely agree that rewriting the tools isn't a useful effort. I > was more concerned that there had been significant development done on > scripts that were intended to be proposed to devscripts and yet were > intentionally being written in a language that I had previously > expressed to Benjamin wasn't used in devscripts. No Python script comes to my mind that was intended to be proposed to devscripts before the language decision was made. add-patch and edit-patch were written in Shell because they were intended to be proposed to devscripts. *-distro-info (formerly *-release-info) were intended to be a stand-alone package when I initially wrote them. After the package was rejected by the ftp-master, I proposed them to devscripts. A while ago I put it into ubuntu-dev-tools after splitting the script into a library and a frontend, because I wanted to use the library in another Python script in ubuntu-dev-tools (sponsor-patch). > I'm not categorically opposed to having Python scripts in devscripts, > as I do grok Python. My resistance was more due to the process around > the proposed contributions and posing the barrier to acceptance as > purely an added dependency. > > Also, while Benjamin and Stefano have offered to support the potential > new scripts, how does that help with the existing scripts which Benjamin > stated concern about? I was sucked in the ubuntu-dev-tools maintenance due to one script that I wrote. I assume that may happen with devscripts too. > Last we spoke, he wasn't comfortable with Perl, > so while they may support their scripts within devscripts, how much does > it really buy for the devscripts package as a whole? I bough a copy of "Learning Perl" (translated into my native language). That's at least a starting point. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: new scripts and patches for devscripts
Am Donnerstag, den 10.03.2011, 18:32 +0100 schrieb Mehdi Dogguy: > On 08/03/2011 23:01, Benjamin Drung wrote: > > > > check-symbols > > I always hated programs that do "sudo" (and even more those doing it > *twice*). And, isn't just unpacking the .deb and checking for ".so" > there enough? You could have undefined symbols… but that may not be > an issue most of the time, IMO. (when diffing like in this case). Yes, this script need to be un-Ubuntu-fied. > > pbuilder-dist > > cowbuilder-dist > > mk-sbuild > > Those could be integrated in pbuilder/cowbuilder/sbuild as examples, IMHO. Good idea. That's even better than devscripts. > > pull-debian-source (?) > > apt-get source $src ? Not really, because for "apt-get source $src" you need an entry in your sources.list. With "pull-debian-source $src experimental" you get the experimental package, with "pull-debian-source $src lenny" you get the lenny package, and so on. > > reverse-build-depends > > This is "build-rdeps", already in devscripts, afaik. Then let's check if some functionality from reverse-build-depends should be merged into build-rdeps. > > suspicious-source what-patch > > I thought that the reason for this script to exist is to be used by other > scripts (like edit-patch, or add-patch) but it seems like it's not. I'm > not even sure that it helps beginners since it hides some very basic > information that every new maintainer should learn. Am I wrong here? suspicious-source is a tool to find pre-generated files (files not in the preferred form for editing). what-patch is a fast way to detect the patch system instead of looking in debian/source and checking debian/README.source and debian/control. Every new maintainer should know how to get this information without what-patch. With dpkg-source 3.0 (quilt) format the benefit of this script degrades. > Encouraging people to document how they patch their package could be > a better initiative, IMHO. > > > Most of the script are written in Python. Rewriting them to get them > > included in devscripts is too much work without benefit. devscripts > > would depend on python then. > > > > I suspect that the number of scripts to be moved is quite low. Moreover, > most of them are very simple and can be rewritten very easily. Is > rewriting them not an option? Rewriting them needs time and could cause new bugs. There are real benefits. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Contact copyright holder / ask for free software license
Am Donnerstag, den 09.10.2014, 10:53 +0200 schrieb Filippo Rusconi: > Greetings, > > On Thu, Oct 09, 2014 at 01:51:31AM +0200, Michael Ole Olsen wrote: > >Contacting copyright holder and asking them to release under > >GPL or such is not a bad idea. > >even if they say no they might consider it in the future. > > Even better, in my experience, if the mail introducing the problem is > well conceived, the authors are generally favourable. Especially if > they did not license their software at all. Recently it took me one > single mail to go from a proprietary license state to a GPL3+ licensed > state. I usually offer two licenses as examples, even providing a > short explanation of the choice between "permissive" (BSD-3-clause) > and "restrictive" (GPL3). All of this also applies to documentation > (and is part of my experience). Usually, making authors switch from > the almost automatic "All rights reserved" motto to GPL (or similar) > is not unfeasible. Do we have a wiki page or similar containing this information? It would be nice to have a page for guiding people (that are unaware, but not against free software) to make good license choices. -- Benjamin Drung System Developer ProfitBricks GmbH - The IaaS-Company Greifswalder Str. 207 D - 10405 Berlin Mail: benjamin.dr...@profitbricks.com Fax: +49 30 577 008 598 URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506 B. Geschäftsführer: Andreas Gauger, Achim Weiss. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1412849922.2913.4.ca...@konstrukt.pb.local
Bug#767246: ITP: pyapi-gitlab -- Python wrapper for the GitLab API
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: pyapi-gitlab Version : 6.2.3 Upstream Author : Itxaka Serrano Garcia * URL : https://github.com/Itxaka/pyapi-gitlab * License : GPL-3 Programming Lang: Python Description : Python wrapper for the GitLab API pyapi-gitlab is a wrapper to access all the functions of the Gitlab API from Python scripts. The binary packages will be called python-gitlab and python3-gitlab. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141029150513.10281.72129.report...@konstrukt.pb.local
Bug#769304: ITP: graypy -- Python logging handler that sends messages in GELF
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: graypy Version : 0.2.11 Upstream Author : Sever Băneşiu * URL : https://github.com/severb/graypy * License : BSD Programming Lang: Python Description : Python logging handler that sends messages in GELF This package can be used to sent messages to Graylog2 using a custom handler for the builtin logging library in the Graylog Extended Log Format (GELF). . Alternately, GELFRabbitHandler can be used to send messages to RabbitMQ. Your Graylog2 server needs to be configured to consume messages via AMQP then. This prevents log messages from being lost due to dropped UDP packets (GELFHandler sends messages to Graylog2 using UDP). You will need to configure RabbitMQ with a 'gelf_log' queue and bind it to the 'logging.gelf' exchange so messages are properly routed to a queue that can be consumed by Graylog2 (the queue and exchange names may be customized to your liking). . graypy can be easily integrated into Django's logging settings. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141112161522.10738.45463.report...@konstrukt.pb.local
Re: (deferred) bits from the DPL: March 2012
Am Sonntag, den 15.04.2012, 20:19 +0200 schrieb Stefano Zacchiroli: > - as part of a discussion on unofficial "debian" repositories [9], Which discussion? ;) > I've > proposed to open up the list of *.debian.net domains. As nobody > disagreed, consensus has been quickly reached and the announced [10] > change is now imminent. Thanks to Carsten Hey and Gerfried Fuchs for > their help in figuring out the details of the last discussion on the > matter and DSA for their feedback. > > [10] https://lists.debian.org/debian-devel-announce/2012/03/msg8.html -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Bug#679547: ITP: ben -- toolbox for Debian maintainers
Am Freitag, den 29.06.2012, 19:21 +0200 schrieb Mehdi Dogguy: > Package: wnpp > Severity: wishlist > Owner: Mehdi Dogguy > > * Package name: ben > Version : 0.6 > Upstream Author : Mehdi Dogguy and Stéphane Glondu > * URL : http://ben.debian.net/ > * License : AGPL-3+ > Programming Lang: C, OCaml > Description : toolbox for Debian maintainers > > This is a collection of useful tools that Debian maintainers can use > to make their packaging work easier. They all work with regular > Debian package list files, and should be useful for Debian > derivatives as well. This package ships a single executable, "ben", > with the following subcommands: > * download: download a set of package list files from a mirror > * monitor: monitor the status of a set of packages across several > architectures (useful for transitions) > * query: query packages using their metadata (similar to grep-dctrl, > but uses a dedicated query language) > * tracker: frontend to multiple monitors What does ben stand for? Is this just a short name for me? ;) Would it be useful to have ben in devscripts instead of a separate package? -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Finding missing epochs
Am Donnerstag, den 05.07.2012, 23:34 +0200 schrieb Jakub Wilk: > I wrote a tool to detect versioned (build-)dependencies with possible > missing (or insufficient) epochs. The results for unstable and a DD-list > are attached. Thanks. Your tool found a missing epoch in vlc, which I fixed now. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: About the media types text/x-php and text/x-php-source
Am Freitag, den 24.08.2012, 23:28 +0200 schrieb Ondřej Surý: > Chris, this is surely not critical severity. I have cloned your bug > report, assigned it a right severity and retitled it to "mime-support: > use of text/ for interpreted languages is discouraged" since we have > several interpreted languages in our mime.types > > text/x-perl > text/x-python > text/x-tcl > text/x-sh > text/x-java > text/x-haskell > [...] Java and Haskell are compiled, but not interpreted languages. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package
Am Dienstag, den 14.05.2013, 20:35 +0900 schrieb Osamu Aoki: > Hi, > > On Mon, May 13, 2013 at 02:31:43PM +0200, Benjamin Drung wrote: > > Am Montag, den 13.05.2013, 21:06 +0900 schrieb Osamu Aoki: > > > This may be still buggy and may needs some more work. I was thinking to > > > update maint-guide using this so I need to be less wordy and the debmake > > > program does more. > > > > Should packaging-dev recommend debmake? > > Not yet. dh-make should be the standard operationg procedure. > > Let's see how this new debmake program is percieved by others first. Okay. Feel free to file a bug against packaging-dev once you consider it mature enough. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368571699.1595.2.camel@deep-thought
Re: Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR
Am Donnerstag, den 23.05.2013, 08:51 +0200 schrieb Bjoern Meier: > hi, > > 2013/5/23 Ondřej Surý : > > Joss isn't the only one to blame. Could all please stop bashing each > other (and Joss) and stick back to technical arguments? (Saying "I'm > sorry" privately to each other for each ad hominem argument used in > this thread would also help!) > > > > I can clearly see what has provoked this reaction and I have a deep > understanding for it. > > > > Ondřej Surý > > P.S.: You should also stop using phrases like "five years old" - > using the word "inappropriate" would make your email still correct, > but not so dishonesting. > > could everybody just please stop spamming? (my first and last attempt. > I don't need a list of 'good guys' with watchguard behavior All I > read is:"Mimimimimi!" in ALL directions. Ondřej Surý is not spamming. He raises an important issue. Insults and disrespectful behavior on debian-devel are not welcome. There is no excuse for such behavior. You might have a thick skin and disagree, but not everyone is happy to deal with bad manners. So I ask for considerateness. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1369345132.2889.17.camel@deep-thought
Re: MBF: transition from texi2html to texinfo
Am Dienstag, den 28.05.2013, 22:45 -0400 schrieb Ryan Kavanagh: > On Tue, May 28, 2013 at 05:08:06PM -0700, Steve Langasek wrote: > > There have been two responses to your proposal so far, neither of > > which particularly looks to be in favor of your plan. I don't think > > it's reasonable to proceed with a mass-bug filing on over 800 packages > > as a first step, certainly not after such a short comment period. > > Sorry, I was overly eager in pushing this change. Thanks Steve for being > the "tempering voice of reason". > > As for the package count, where did you find the additional 700+ > packages? If I'm missing something, please let me know. Of matches in > the search[0] Paul Wise linked to, many matches are from the same > package, or more prominently (as with e.g., festival, gcc, geiser, > id-utils, gcl, etc.), found in the upstream build system but never > called at build time (one can deduce this from the fact that they don't > build-depend on texi2html). As I stated in my initial email, there are > at most 96 packages which would require some form of change, and these > are the packages that either build-depend (94) or depend (2) on > texi2html. Have you checked indirect build-dependencies on texi2html (e.g. the package build depends on foo, which depends on texi2html)? -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1369819747.2863.4.camel@deep-thought
Re: Switching to mozilla ESR in stable-security
Am Donnerstag, den 30.05.2013, 22:29 +0100 schrieb Wookey: > +++ Josh Triplett [2013-05-29 11:50 -0700]: > > Moritz Muehlenhoff wrote: > > > One problematic aspect are the various xul-ext-* packages currently > > > packaged. It's very likely that some of them will break with ESR17 > > > and ESR24 in the future. > > > > > > However, there's not much we can do here. We can select a narrow (!) > > > set of important addons (e.g. enigmail for Icedove) that we will > > > keep in sync through stable-security, but that doesn't scale for > > > the full scale of Mozilla extensions currently packaged. > > > > > > In the future the majority of packages should thus rather be installed > > > through http://addons.mozilla.org instead of Debian packages. > > > > As a user of sid who also maintains various systems running stable, I > > rely on packages like xul-ext-adblock-plus to make it easier to install > > specific addons systemwide. I find it much easier to install those via > > the Debian packaging system rather than a user-level mechanism that > > involves running Firefox as one or more target users (or more likely > > doing the equivalent of creating a xul-ext-* package for local use). I > > realize that you can't maintain the full library of Firefox addons as > > packages, but I'm hoping that some of the most common and popular ones > > stick around and stay up to date, notably Adblock Plus, HTTPS > > Everywhere, and It's All Text. > > Absolutely, and I'd like to add lazarus, noscript, ghostery, user-agent > switcher, and debian-buttons to that list of 'can't-live-without, worth > maintaining as packages' add-ons. (And Tab Mix Plus is exceedingly > handy too) > > Obviously if no-one wants to maintain them then I guess we'll have to > get them the way everyone else does, but I certainly find real value > in having them packaged, and am pleased every time I can get an add-on > that way. Do we have helpers (as for CPAN and similar archives) to > make creation and maintenance of such packages simple? mozilla-devscript is the helper to create xul-ext packages. It helps installing the .xpi file in the right place and creates the dependency lists. We have a wiki page [1] with a usage explanation. PS: It would be good to have this wiki page content converted to a man page that we could ship with the mozilla-devscript package. Help doing this would be appreciated. [1] http://wiki.debian.org/mozilla-devscripts > If it wasn't too hard I'd be happy to maintain xul-ext-lazarus, for example. It is simple in most cases. You often just repack the .xpi file. Do you mean "Lazarus: Form Recovery" with xul-ext-lazarus [my first connection was the Lazarus IDE for Pascal]? This extension is labeled as "Freeware" and therefore not DFSG-free. You have to convince upstream to relicense the package before it can enter the main archive. I don't think that it makes sense to packaging non-free xul extensions in the Debian archive. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370094430.3020.14.camel@deep-thought
Re: Why not to let all DDs to execute "gb"-command
Am Mittwoch, den 05.06.2013, 21:10 +0200 schrieb Anton Gladky: > Dear all, > > I have a proposal to give a permission to all DDs to restart builds on > failing archs e.g. execute "gb-command". > > I think, most of developers are clever enough to define, whether the > built failed "accidentally" and needs to be restarted, or it requires > some fixing and uploading new version. It will save time for both DDs > and wb-team. +1 In Ubuntu, developers can restart builds on failing archs (via Launchpad) for package that they can upload. I used that feature several times. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370469962.12617.12.camel@deep-thought
Re: Default desktop for jessie Was: Re: Debian/Wheezy general rant ...
Am Mittwoch, den 05.06.2013, 15:02 -0700 schrieb Russ Allbery: > Svante Signell writes: > > > Not everybody agrees to that, there is a split opinion about this. > > Please lift this discussion a little higher: Which would be the default > > desktop for jessie? > > Because we weren't having enough fun with systemd vs. upstart and the MTA > discussion. :) Maybe if we can start all the flamewars at once, we'll > get destructive interference! > > udev sucks! Debian should hire a developer to replace all uses of CDBS > with dh! Perl should be replaced with Python in essential! All packages > need to switch to 3.0 (quilt)! Native packages should be banned! No one > should ever be allowed to NMU anything ever if the maintainer says no! > > Did I miss anything? Software has bugs (including RC bugs)! Without bugs, we could have 0-day long freezes and could drop testing completely. :) -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370472907.12617.45.camel@deep-thought
Bug#714449: ITP: droopy -- mini web server to let others upload files to your computer
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: droopy Version : 20120108 Upstream Author : Pierre Duquesne * URL : http://stackp.online.fr/droopy * License : BSD-3-clause Programming Lang: Python Description : mini web server to let others upload files to your computer Droopy is a mini Web server whose sole purpose is to let others upload files to your computer. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130629133515.27128.15828.reportbug@deep-thought
Bug#714459: ITP: pyhunspell -- Python 2/3 binding for Hunspell
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: pyhunspell Version : 0.1 Upstream Author : Sayamindu Dasgupta * URL : https://code.google.com/p/pyhunspell/ * License : GPL-3+ Programming Lang: C, Python Description : Python 2/3 binding for Hunspell Pyhunspell is a set of Python bindings for the Hunspell spell-checker engine. It lets developers load Hunspell dictionaries, check words, get suggestions, add new words, etc. It also provides some basic morphological analysis related methods. There are two binary packages. One provides the binding to Python 2 and the other provides the binding to Python 3. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130629155516.26765.27018.reportbug@deep-thought
Bug#715169: ITP: adblockedge -- Advertisement blocking extension for web browsers
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: adblockedge (binary: xul-ext-adblock-edge) Version : 2.0.4 Upstream Author : adstomper * URL : https://bitbucket.org/adstomper/adblockedge/ * License : MPL-2.0 Programming Lang: JavaScript Description : Advertisement blocking extension for web browsers Adblock Edge is a content-filtering extension for Iceweasel, Firefox, SeaMonkey, and several other applications; it allows users to prevent webpage elements, such as advertisements, from being downloaded and displayed. On the first run, Adblock Edge will ask you if you want to subscribe to a filter list, which is automatically updated and blocks a lot of common advertisements. Additional filters can be added at will, and it's also possible to use wildcards in order to block e.g. all images or JavaScript files from specific servers or directories. Adblock Edge is a fork of the Adblock Plus version 2.1.2 extension for blocking advertisements on the web. This fork will provide the same features as Adblock Plus 2.X and higher but without "acceptable ads" feature. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130706153208.626.70568.reportbug@deep-thought
Re: Looking for ideas for merging a micro package...
Am Dienstag, den 03.09.2013, 22:18 -0700 schrieb Russ Allbery: > tony mancill writes: > > > Thank you for pointing this out. I just recently uploaded a script, > > splitpatch, that I argued should be accepted as-is (i.e. as a "micro > > package") because of the dependency on ruby. > > > Given that ruby is becoming more popular for scripting, what do folks > > think about a catch-all package for ruby scripts? I don't have a good > > feel for what the right trade-off is between: > > > * reducing load on the archive by consolidating these tiny packages > > > * making good use of maintainer's time, the implication being that > > coordinating multiple (otherwise unrelated?) ruby scripts is going to be > > more of a time commitment for the maintainer(s) > > > and > > > * making it easy (or even possible) for users to find these scripts when > > the package name doesn't match upstream > > I think it makes a ton of sense to have several of these catch-all > packages split by implementation language. The biggest advantage is to > the maintenance of the catch-all package; most of us only consider > ourselves highly experienced in, or comfortable in, one or two languages, > and therefore it's harder to find maintainers who are comfortable with > packages that mix a bunch of languages. It's also helpful to be tied in > to the maintenance community for that language to weigh things like good > modules to rely on or not rely on, how burdensome dependencies are, etc. > There's also a minor advantage for the user who may not want to introduce > a whole new interpreter to systems that are tight on space or that need to > be kept simple. > > A moreutils-ruby (or some similar name) seems like a great idea to me. > > I would check with Joey first, though, just in case he disagrees with that > reasoning and would prefer to include the scripts directly in moreutils. > > (splitpatch might make more sense in devscripts, but devscripts I think > has the same set of constraints, albeit with different base languages. > Python and Perl at the moment, I think.) devscript had only Perl and Shell scripts initially, but then gained Python scripts. I don't see any reason to not accept ruby script. ruby would pull in another ~ 13 MB of storage, but devscripts targets developer machines. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1378285972.3306.3.camel@deep-thought
Re: how do deal with versionless mercurial software ?
On Fr, 2013-10-04 at 13:40 +0200, Dominik George wrote: > Vincent Lefevre schrieb: > >Then, do you mean that VCS hashes are sortable? > > Of course not. One would have to do something like 0~MMDDnn > +git in that rare case. > > My argument for keeping the VCS hash is to ease identifying the code > in the package. You could put the VCS hash as text in the changelog entry, e.g. "New upstream snapshot (git commit )." and just use the date as Debian version (0~MMDD or 0.MMDD). In case you need to release two upstream snapshots on the same date, you can append .2 (0~MMDD.2). -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1381869150.2681.3.camel@erde
Bug#645212: ITP: lxmms2 -- control XMMS2 with a LIRC compatible remote control
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: lxmms2 Version : 0.1.3 Upstream Author : Johannes Heimansberg * URL : http://wejp.k.vu/projects/xmms2/lxmms2 * License : GPL-2 Programming Lang: C Description : control XMMS2 with a LIRC compatible remote control lxmms2 is a tiny XMMS2 client to control XMMS2 with a LIRC compatible remote control. Following actions are supported: - play (starts playback) - pause (pauses playback) - toggle_play_pause (toggles pause and starts playback if XMMS2 is not playing at all) - toggle_pause (toggles pause) - stop (stops playback) - next (advances to the next track) - prev (goes back to the previous track) - volume_up (increases the volume) - volume_down (decreases the volume) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111013155848.14230.23978.reportbug@localhost6.localdomain6
Re: Announcing derivatives patches and call for help and feedback
Am Mittwoch, den 26.10.2011, 08:49 +1100 schrieb Karl Goetz: > On Tue, 25 Oct 2011 13:57:20 +0200 > Mehdi Dogguy wrote: > > > On 25/10/2011 09:50, Paul Wise wrote: > > > > > > For the presentation side of things I am thinking one approach > > > might be to move UbuntuDiff[8] to the QA infrastructure, generalise > > > it and enhance it for this purpose. This will necessarily include > > > mechanisms to mark patches as having been dealt with or ignorable. > > > > > > 8. http://ubuntudiff.debian.net/ > > [...] > > > About source code, it is written in OCaml. I realize that OCaml is > > not the best candidate if we want people to contribute patches (or > > even have a look at the code) :) It depends on who wants to > > contribute here. I'm open to suggestions… > > If integration with PTS is planned (and or if you're using > ubuntu-distro-info) perhaps python would make sense as a language > choice. ubuntu-distro-info is implemented in Haskell (since version 0.3) and has an Python and Perl library. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
DEP-5 and files with white spaces
Hi, DEP-5 is nice, but how can I specify a license for a file with white spaces? For example you want to specify that the file "foo/file one.bar" is licensed under ISC, but "foo/file_one.bar" is licensed under GPL. How can you do that? I would like to write following: File: "foo/file one.bar" License: ISC File: foo/file_one.bar License: GPL -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 14:20 -0800 schrieb Russ Allbery: > Benjamin Drung writes: > > > DEP-5 is nice, but how can I specify a license for a file with white > > spaces? For example you want to specify that the file "foo/file one.bar" > > is licensed under ISC, but "foo/file_one.bar" is licensed under GPL. How > > can you do that? > > No, that distinction isn't representable. There was some earlier > discussion about that, and the conclusion reached was that it was a rare > case that wasn't worth making the syntax more complicated (after various > more complicated syntaxes were tossed around without making anyone very > happy). Is it to complex to have a syntax that is similar to what the shell does? Two solutions pop into my mind. Please let me know, why these are not use. You can point me to previous discussions. Idea 1: Use a escape sequence for specifying a whitespace (e.g. "\ " for a space). Idea 2: Allow quotation marks. > The general way to specify information for a file name that contains > whitespace is to use wildcards to match the whitespace, which means that > you can't disambiguate from other files that only differ in the places > where whitespace is present. I don't like the idea of abusing a wildcard if the files could be specified more precisely. > Out of curiosity, have you run across a case where this matters, or were > you asking because it's a theoretical hole? It's definitely a theoretical > hole, but one of the reasons why we didn't spend more time on it was that > everyone was dubious that the case would arise in a real-world situation. I haven't run across an actual case. This case just popped into my mind and I wondered how to cover this case. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 23:31 +0100 schrieb Jakub Wilk: > * Russ Allbery , 2012-02-01, 14:20: > >>DEP-5 is nice, but how can I specify a license for a file with white > >>spaces? For example you want to specify that the file "foo/file > >>one.bar" is licensed under ISC, but "foo/file_one.bar" is licensed > >>under GPL. How can you do that? > > > >No, that distinction isn't representable. > > This one is representable. You can take advantage of the fact the "the > last paragraph that matches a particular file applies to it": > > | Files: foo/file?one.bar > | License: ISC > | > | Files: foo/file_one.bar > | License: GPL > > That said, you _can_ construct even more contrived examples which are > unrepresentable, e.g. by replacing "_" with a tab. > > >The general way to specify information for a file name that contains > >whitespace is to use wildcards to match the whitespace, > > That works only if you can stand ugliness of such Files fields. True words. For example, the eclipse source package has files with spaces in it using ? instead of spaces does look ugly. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 14:49 -0800 schrieb Russ Allbery: > Benjamin Drung writes: > > > Is it to complex to have a syntax that is similar to what the shell > > does? Two solutions pop into my mind. Please let me know, why these are > > not use. You can point me to previous discussions. > > > Idea 1: Use a escape sequence for specifying a whitespace (e.g. "\ " for > > a space). > > > Idea 2: Allow quotation marks. > > Yeah, both of those were among the other syntax proposals that were > suggested, and I think one of them was in the document at one point. > Using backslash is probably the easiest, although it does make parsing the > files harder. IMHO allowing both would be the optimum. A real parser would have problems with both, but a simplistic "parser" that just split the string by spaces would have a problem. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: DEP-5 and files with white spaces
Am Mittwoch, den 01.02.2012, 14:56 -0800 schrieb Russ Allbery: > Benjamin Drung writes: > > Am Mittwoch, den 01.02.2012, 14:49 -0800 schrieb Russ Allbery: > > >> Yeah, both of those were among the other syntax proposals that were > >> suggested, and I think one of them was in the document at one point. > >> Using backslash is probably the easiest, although it does make parsing > >> the files harder. > > > IMHO allowing both would be the optimum. A real parser would have > > problems with both, but a simplistic "parser" that just split the string > > by spaces would have a problem. > > Yeah, that was, as I understand it, the motivation (to allow really simple > parsers). What is more important: A "good looking" copyright file or being parsable by a dead simple, stupid parser? The proposed changes would make the parser overly complex. > I don't know if it's worth revisiting this. I can't say that I > particularly liked the outcome we arrived at, but theoretical holes in > standards bother me a lot (possibly more than they should). I would call a theoretical hole a design bug. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: leaks in our only-signed-software fortress
Am Samstag, den 18.02.2012, 11:48 +0100 schrieb Thomas Koch: > July 2011 VLC suffers from Companies spreading Malware bundled with VLC This is no problem for us, because the malware was distributed on some untrustworthy websites. We, as packagers, get the code directly from the Videolan project. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Bug#663647: ITP: npapi-vlc -- multimedia plugin for web browsers based on VLC
Package: wnpp Severity: wishlist Owner: Benjamin Drung * Package name: npapi-vlc Version : 2.0.0 Upstream Author : VLC media player developers * URL : http://git.videolan.org/?p=npapi-vlc.git * License : GPL-2+ Programming Lang: C++ Description : multimedia plugin for web browsers based on VLC This plugin adds support for MPEG, MPEG2, DVD, DivX, Ogg/Vorbis and many more formats to your Gecko-based web browser (Firefox, Galeon, etc.). The decoding process is done by VLC and the output window is embedded in a webpage or directly in the browser window. There is also support for fullscreen display and javascript control. . VLC is the VideoLAN project's media player. It plays MPEG, MPEG-2, MPEG-4, DivX, MOV, WMV, QuickTime, WebM, FLAC, MP3, Ogg/Vorbis files, DVDs, VCDs, podcasts, and multimedia streams from various network sources. The browser plugin was part of the vlc source tarball, but is now separated from the vlc source tarball and shipped as separate npapi-vlc tarball. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312225006.9527.15176.reportbug@localhost6.localdomain6
Re: (seemingly) declinging bug report numbers
Am Donnerstag, den 11.10.2012, 16:14 -0400 schrieb Paul Tagliamonte: > On Thu, Oct 11, 2012 at 09:45:58PM +0200, Simon Josefsson wrote: > > Marco Nenciarini writes: > > > > > Il giorno gio, 11/10/2012 alle 02.46 +0200, Christoph Anton Mitterer ha > > > scritto: > > >> > > >> On the other hand, some worries are there that this could imply some > > >> decline in Debian itself. > > >> Well I still think Debian is the best distro out there for most (if not > > >> all cases), even though I'd like to see it putting more emphasis on > > >> security. > > > > > > I've seen recently several company I'm working with getting away from > > > Debian in favor of Ubuntu because they have a LTS version. However I > > > don't know if this is a general trend. > > > > I can confirm the trend for a couple of organisations. The primary > > reason that I identified was the retirement of security support for > > Lenny and that Lenny packages are removed from many Debian mirrors which > > made it difficult to use Lenny machines. IMHO, supporting an OS release > > for only 3 years is not long enough. > > FWIW, it should be noted Ubuntu only supports most packages for 3 years > as well. The subset of packages considered for "Server" support is > supported for 5, but most people will suggest you follow the LTS upgrade > path, which is very similar to Debian Stable's. Since Ubuntu 12.04 LTS, the LTS versions are supported for five years on the desktop, too. [1] https://wiki.ubuntu.com/LTS -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Popularity of bzr-builddeb and dh-make
Hi, How popular are bzr-builddeb and dh-make in Debian? The current situation is that packaging-dev recommends bzr-builddeb and suggests dh-make. It was requested to drop bzr-builddeb from Recommends and add dh-make [1]. The recommended packages of packaging-dev should be recommended by most of the Debian developer and not just by the maintainer of packaging-dev or one single bug reporter. Therefore I am asking you: How popular are bzr-builddeb and dh-make? Should they be recommended or just suggested by packaging-dev? [1] http://bugs.debian.org/688572 -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Popularity of bzr-builddeb and dh-make
A poll is a good idea. Can you recommend a site that allows setting up a poll? Am Donnerstag, den 11.10.2012, 23:29 +0200 schrieb Matthias Klumpp: > Hi! > Have you considered making a poll for this? Because everyone will tell > you a different oppinion... > For me, I think: bzr-builddeb is specific to Bzr, if you don't use > Bzr, it is useless. Instead, dh_make can be used to generate Debian > templates quickly, so it might be useful for more people, even those > not using Bzr. > I use the Debian Git tools for packaging, I never touched the Bzr > stuff, so I don't need it. I also don't need dh-make often, but it > sometimes is useful. > I can't give any hint, because I am just one developer, but I would > probably prefer dh-make for the reason above. > But if I would need to decide, I would probably suggest both and > recommend none of them :-) > Cheers, >Matthias > > 2012/10/11 Benjamin Drung : > > Hi, > > > > How popular are bzr-builddeb and dh-make in Debian? The current > > situation is that packaging-dev recommends bzr-builddeb and suggests > > dh-make. It was requested to drop bzr-builddeb from Recommends and add > > dh-make [1]. The recommended packages of packaging-dev should be > > recommended by most of the Debian developer and not just by the > > maintainer of packaging-dev or one single bug reporter. Therefore I am > > asking you: How popular are bzr-builddeb and dh-make? Should they be > > recommended or just suggested by packaging-dev? > > > > [1] http://bugs.debian.org/688572 > > > > -- > > Benjamin Drung > > Debian & Ubuntu Developer -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Popularity of bzr-builddeb and dh-make
Am Donnerstag, den 11.10.2012, 14:38 -0700 schrieb Steve Langasek: > Hi Benjamin, > > On Thu, Oct 11, 2012 at 10:38:08PM +0200, Benjamin Drung wrote: > > How popular are bzr-builddeb and dh-make in Debian? The current > > situation is that packaging-dev recommends bzr-builddeb and suggests > > dh-make. It was requested to drop bzr-builddeb from Recommends and add > > dh-make [1]. The recommended packages of packaging-dev should be > > recommended by most of the Debian developer and not just by the > > maintainer of packaging-dev or one single bug reporter. > > I think this is a failing proposition. There are as many different > preferences about packaging, to the nearest order of magnitude, as there are > Debian developers. I'm fine with this package being one maintainer's > recommendations for some packages; I'm not at all ok with it being recast as > a blessed recommendation of the project, as I object to about a third of the > stuff in there. The main purpose of this package is to help beginners to get ready for packaging and not making a recommendation statement for the Debian project. The question is: Will you recommend newcomers to install packaging-dev to start packaging? Will installing packaging-dev be enough or will you recommend to install bzr-builddeb or dh-make afterwards? > > Therefore I am asking you: How popular are bzr-builddeb and dh-make? > > Should they be recommended or just suggested by packaging-dev? > > dh-make isn't so relevant now that debhelper 7 exists. cp > /usr/share/doc/debhelper/examples/rules.tiny debian/rules && dch > --create, manually create debian/control and debian/copyright, and that's > about it. That's my opinion, too. > bzr is the fourth most popular version control system in Debian according to > <http://upsilon.cc/~zack/stuff/vcs-usage/>. If you're going to demote > bzr-builddeb (which doesn't bother me), I think you should also be demoting > svn-buildpackage, because svn is horrible and should die. I agree that Subversion should die, but it is still widely used. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: (seemingly) declinging bug report numbers
Am Freitag, den 12.10.2012, 00:00 +0200 schrieb Vincent Bernat: > ❦ 11 octobre 2012 22:33 CEST, Benjamin Drung : > > >> > I can confirm the trend for a couple of organisations. The primary > >> > reason that I identified was the retirement of security support for > >> > Lenny and that Lenny packages are removed from many Debian mirrors which > >> > made it difficult to use Lenny machines. IMHO, supporting an OS release > >> > for only 3 years is not long enough. > >> > >> FWIW, it should be noted Ubuntu only supports most packages for 3 years > >> as well. The subset of packages considered for "Server" support is > >> supported for 5, but most people will suggest you follow the LTS upgrade > >> path, which is very similar to Debian Stable's. > > > > Since Ubuntu 12.04 LTS, the LTS versions are supported for five years on > > the desktop, too. > > > > [1] https://wiki.ubuntu.com/LTS > > This only applies to "main", right? main + restricted are supported by Canonical. universe + multiverse are supported by the community (in a best effort manner). -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Poll (was: Popularity of bzr-builddeb and dh-make)
Am Freitag, den 12.10.2012, 10:04 +0800 schrieb Paul Wise: > On Fri, Oct 12, 2012 at 5:35 AM, Benjamin Drung wrote: > > > A poll is a good idea. Can you recommend a site that allows setting up a > > poll? > > The Debian secretary was at one point going to setup devotee for this > sort of thing, don't think that ever happened though. > > If you want some FSAAS (free-software-as-a-service), search for doodle > on this page: > > https://wiki.debian.org/FreedomBox/LeavingTheCloud Thanks. I have setup a poll for it: https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/ The poll will be closed in one week (if enough votes are collected). -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Poll (was: Popularity of bzr-builddeb and dh-make)
Am Freitag, den 12.10.2012, 21:13 +0900 schrieb Hideki Yamane: > - bzr-builddeb is, well, it seems that is useful in UDD (Ubuntu Distributed > Development, as Ubuntu packaging guide says) way, but now it heavily > relies on Launchpad in my point of view. How does bzr-builddeb depend on Launchpad? bzr is integrated into Launchpad, but you can use bzr without Launchpad as every other DVCS. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Vote result (was: Poll (was: Popularity of bzr-builddeb and dh-make))
Hi, the week is over and here are the results from the vote: There were 64 participants in total. dh-make === 46 people want dh-make recommended. 27 people (+ 3 with a question mark) want dh-make suggested. 58 people voted for (at least) one of the above options. Recommending dh-make instead of suggesting was the clear winner. I will move dh-make from Suggests to Recommends in packaging-dev. bzr-builddeb 8 people (+ 3 with a question mark) want bzr-builddeb recommended. 30 people (+ 10 with a question mark) want bzr-builddeb suggested. 44 people voted for (at least) one of the above options. What will I do? Am Samstag, den 13.10.2012, 00:10 +0900 schrieb Charles Plessy: > Le Fri, Oct 12, 2012 at 12:06:11PM +0200, Benjamin Drung a écrit : > > Am Freitag, den 12.10.2012, 10:04 +0800 schrieb Paul Wise: > > > > https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/ > > > > The poll will be closed in one week (if enough votes are collected). > > Hello everybody, > > if the point is to have a package that pulls everything one needs when doing > random work in Debian (as opposed with working specifically in one team where > it is predictable which helpers are used and which are not), then I do not > understand the point of not including *-buildpackage and dh-make, which are > tiny regarding to most other things that mk-builddeps will pull in later. > > I think that it is exactly the case where we should not vote. Unless the > wheight of bzr and dh-make is unbearable to otherwise users of packaging-dev, > even if the majority do not use them, what is the harm recommending them ? > Not to mention that there is no evidence that the people who vote for or > against recommending them are really using packaging-dev... I agree with your opinion. packaging-dev targets especially newcomers and should give them a good starting point. It should allow doing random work in Debian and therefore recommends packages that are used by a portion (could be lower than 50%) of Debian developers. For example, gnome-pkg-tools and pkg-kde-tools are recommended. Not every developer touches a GNOME or KDE packages, but these desktop environments are important enough to recommend these helpers. The poll showed that bzr-builddeb is wanted by a portion of developers (18 % up to 25 %), but not by most of them. Therefore I will keep bzr-builddeb recommended until someone has another good reason to demote the package to suggests. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Bits from the release team - Freeze update
Am Donnerstag, den 08.11.2012, 19:21 + schrieb Neil McGovern: > On Thu, Nov 08, 2012 at 05:18:55PM +, Jon Dowland wrote: > > On Thu, Nov 08, 2012 at 10:40:18PM +0800, Paul Wise wrote: > > > Which policy applies to #685913 (and all the other open unblocks)? The > > > policy announced at the beginning of the freeze or the current policy? > > > > …or the time the unblock was filed? > > > > Apologies for the lack of clarity in the d-d-a posting - the new > acceptance criteria are for unblocks filed after 11:54:49 + today. Hm, I filed two unblock requests after that deadline, but before reading the announce mail about it. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1352402942.25394.18.camel@deep-thought
Re: Bits from the release team - Freeze update
Am Donnerstag, den 08.11.2012, 20:35 + schrieb Jon Dowland: > On Thu, Nov 08, 2012 at 08:29:02PM +0100, Benjamin Drung wrote: > > Hm, I filed two unblock requests after that deadline, but before reading > > the announce mail about it. > > You don't state whether the decision impacts them or not, but so it goes… The requested updates (for vlc and devscripts) fix bugs, but not release critical bugs. I am unsure whether these updates get unblocked even after the reduced acceptance criteria. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1352413041.10356.3.camel@deep-thought
Re: Bug#692894: ITP: plum -- plum is a command line tool used to interact with the U-Boot netconsole of any LaCie product
Am Samstag, den 10.11.2012, 15:52 +0100 schrieb Maxime Hadjinlian: > On Sat, Nov 10, 2012 at 3:42 PM, Neil Williams wrote: > > On Sat, 10 Nov 2012 13:55:41 +0100 > > Maxime Hadjinlian wrote: > > > >> Package: wnpp > >> Severity: wishlist > >> Owner: Maxime Hadjinlian > >> > >> * Package name: plum > >> Version : 0.1 > >> Upstream Author : Maxime Hadjinlian > >> * URL : http://github.com/maximeh/plum > >> * License : BSD > >> Programming Lang: C++, Python, Shell Scripts > >> Description : plum is a command line tool used to interact with the > >> U-Boot netconsole of any LaCie product > > > > Couldn't the package use a name which is more clearly identified as > > related to either lacie or uboot? The more specific the package name > > the better, unless the package is going to gain support for the uboot > > netconsole on many more products. The package name is far from being as > > specific as the package itself. General purpose names are (relatively) > > fine for general purpose programs. > Well, plum is an acronym for Python LaCie das U-Boot Milchkuh, I'm not > really good at giving names, if you have any idea, feel free to share. Shouldn't it be "die U-Boot Milchkuh" instead of "das U-Boot Milchkuh", because the cow is female? -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1352568825.15946.0.camel@deep-thought
Re: A common configuration format, anyone?
Am Mittwoch, den 14.11.2012, 15:32 +0400 schrieb Игорь Пашев: > > > 2012/11/14 Philip Ashmore > simple format which, like xml, is human-readable > > > XML is not human-readable :-) XML is human-readable, but in most cases ugly to write. IMO XML is not human-writable. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1352907081.2868.1.camel@deep-thought
Re: Bits from the release team - Freeze update
Am Freitag, den 09.11.2012, 10:12 + schrieb Neil McGovern: > On Fri, Nov 09, 2012 at 06:54:23AM +0100, Christian PERRIER wrote: > > Quoting Benjamin Drung (bdr...@debian.org): > > > Am Donnerstag, den 08.11.2012, 20:35 + schrieb Jon Dowland: > > > > On Thu, Nov 08, 2012 at 08:29:02PM +0100, Benjamin Drung wrote: > > > > > Hm, I filed two unblock requests after that deadline, but before > > > > > reading > > > > > the announce mail about it. > > > > > > > > You don't state whether the decision impacts them or not, but so it > > > > goes… > > > > > > The requested updates (for vlc and devscripts) fix bugs, but not release > > > critical bugs. I am unsure whether these updates get unblocked even > > > after the reduced acceptance criteria. > > > > > > Well, I bet that our estimated colleagues in the Release Team are not > > robots, so discussing with them might be possible..:-) > > > > Additionally, the mails didn't make it to the list due to the size of > the attached diff. You may want to consider that an indication of our > willingness to review the provided diff. The version in testing has a known security vulnerability, which was fixed by upstream in their newer upstream release. I sent a more stripped debdiff to make the review easier. Removing Windows/MacOS changes and auto-generated autotools file changes reduces the diff size by factor 2.4. -- Benjamin Drung Debian & Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1353325062.23011.11.camel@deep-thought
