Re: OpenSSL 1.1.0
On Wed, Nov 16, 2016 at 1:58 PM, Pau Garcia i Quiles wrote: [...] > OpenSSL 1.0 only > = [...] > * Some obscure feature (e. g. BlaBla20) may be missing or be difficult > to support on a limited number of packages (e. g. apache2) [...] Sorry, it's ChaCha20, not BlaBla20. My bad. -- Pau Garcia i Quiles http://www.elpauer.org
Re: OpenSSL 1.1.0
On Wed, Nov 16, 2016 at 1:26 PM, Ian Jackson wrote: > A maintainer should be ready to explain, and if necessary change, > decisions they have taken. (Ideally wider consultation before taking > such a decision would be better.) > > In the absence of input from the openssl maintainers, I would like to > ask the Release Team's opinion. > > If we are going to wind back on this change we should do it ASAP. We > should not allow ourselves to make the decision to press on, simply by > failing to decide otherwise. > > If we decide to wind back the transition and the openssl maintainers > continue not to be available (within the short timeframes required), > we have a lot of people who could competently prepare an NMU. >From a project management point of view, I can see three alternatives OpenSSL 1.0 only = * All packages work fine * No release delays * We will be using an LTS version of OpenSSL * Some obscure feature (e. g. BlaBla20) may be missing or be difficult to support on a limited number of packages (e. g. apache2) OpenSSL 1.1 only = * Many packages do not support OpenSSL in upstream, therefore they need patching from Debian maintainer (security risk). Some packages do not have a maintainer volunteer that can provide this patch. * Release delay between 6-12 months seems certain * We will be using version of OpenSSL with support end date before Stretch's support end date * We will be providing all new features that come with OpenSSL OpenSSL 1.0 + 1.1 == * Every package will be buildable but we can expect surprises on runtime due to dlopen'ed libraries, indirect use, etc * Release delay seems certain but difficult to determine * Even with a release delay, we cannot be 100% sure all the rutnime surprises will be gone * We need to support 2 versions of OpenSSL and be prepared for third-party applications (not included with Debian) to fail due to runtime surprises * Different support cycles upstream (one LTSL, one not) * We will be providing both versions of OpenSSL for the end-user to choose (when he has the knowledge) If I were in charge of taking this decision: * OpenSSL 1.0 + 1.1 would be out. It's the worst possible scenario: even with a delay, I can expect problems * OpenSSL 1.1 will delay the release and/or leave a lot of packages out * OpenSSL 1.0 makes possible to release as planned and provides an LTS release. The minor inconveniences for missing ciphers, etc do not justify the negative impact of the other choices, IMO. So I would release Stretch with OpenSSL 1.0 only, and then make a plan: 1. OpenSSL 1.1 is gone from sid effective immediately and move to experimental 2. On April 1st 2017 we replace OpenSSL 1.0 with OpenSSL 1.1 in sid. All packages are expected to support OpenSSL 1.1 only by this date. 3. Stabilize and aim for a quick Debian release 1 year after Stretch. Yes, that means 2 Debian versions supported for some time. Of course, that's just my suggestion. Feel free to disagree. -- Pau Garcia i Quiles http://www.elpauer.org
Re: OpenSSL 1.1.0
On Fri, Nov 4, 2016 at 1:43 AM, Ian Jackson wrote: > I'm concerned that we are setting up a situation where: > > * A maintainer (or interested party) for a package which peripherally >uses openssl; > * Gets an RC bug report; > * Is threatened with autoremoval; > * Does not really know how to respond; > * Does not have useful support from their own upstream because >their own upstream hasn't got to grips with this yet; > * Feels under pressure that they must Fix It Now. > > This seems to be setting ourselves up for failures - particularly, > failures where the package compiles and seems to work, but has some > kind of problem in its use of openssl APIs which constitutes a > security problem. > [...] I fully agree and I have been stating that for months. In fact, yesterday I checked that my package witty now builds fine with OpenSSL 1.1.0 thanks to a new version of Boost. But I suspect there will be something wrong on runtime because witty does link to Qt4, which as Lisandro said recently, does not support OpenSSL 1.1.0. It may fail on runtime. As I requested a few days ago, please delay making OpenSSL 1.1.0 the default for 1 year (and even then, we should be checking the case where something links directly to one version of OpenSSL, and also links to something that dlopen's some other version of OpenSSL). Thank you -- Pau Garcia i Quiles http://www.elpauer.org
Re: openssl transition
On Thu, Oct 27, 2016 at 2:39 PM, Antti Järvinen wrote: > While patching -DOPENSSL_API_COMPAT=0x1010L will help a lot but > code changes are still required in addition to this flag, many > applications allocate OpenSSL data-structures in stack and this is not > supported any more, regardless of -DOPENSSL_API_COMPAT. > > This whole "let's shove OpenSSL 1.1 down your throat" is a very bad idea, IMHO. My upstreams (witty and ace) have no plans to support OpenSSL 1.1 in the next months. I do not have enough knowledge with OpenSSL to feel comfortable with my patches. I may end up rendering the software insecure. Does anyone remember the OpenSSL PRNG incident 10 years ago? Are we trying to repeat it? https://www.schneier.com/blog/archives/2008/05/random_number_b.html Really, this does look like a huge mistake. Packagers will produce patches that will generate suboptimal, if not straight insecure, software just for their packages not to be removed, and/or to stop those "hey hey, RC bug on you!" mails. Please, delay the "only 1.1 migration" for 1 year. -- Pau Garcia i Quiles http://www.elpauer.org
Re: OpenSSL 1.1.0
On Wed, Jun 29, 2016 at 9:49 PM, Moritz Mühlenhoff wrote: > Jérémy Lal wrote > > The openssl release strategy page [1] states: > > Version 1.1.0 will be supported until 2018-04-30. > > Version 1.0.2 will be supported until 2019-12-31 (LTS). > > > > Considering the dates, upstream authors using openssl 1.0.2 might not > > migrate to the new api until 1.0.2 end of life. > > Is it reasonnable, for security and human resources sake, to carry > hundreds > > of patches for a transition that will happen much more safely and > naturally > > later ? > > Certainly. 1.1 brings a lot of internal changes which will be beneficial in > the long run. And of course's there a wide range of 1.1 features which > will b > e important during the lifetime of stretch (e.g. chacha20/poly1305 > support). > > I beg to disagree. IMHO the mandatory migration to OpenSSL 1.1.0 is happening too soon. Most upstreams have do not support 1.1.0 yet, and have no plans to support it in months. This will force Debian maintaners to rewrite OpenSSL code, which is a very sensitive part and may turn an (upstream) secure application into an insecure application due to incorrect patches. If possible, I would rather have both 1.0.2 and 1.1.0 in the archive, and move to 1.1.0 as upstream moves. I do not feel comfortable at all touching security-related stuff, it's not my specialty. Even less if we are talking about OpenSSL, known not to be the most friendly and intuitive APIs. -- Pau Garcia i Quiles http://www.elpauer.org
Re: Packaging of static libraries
On Sun, Apr 10, 2016 at 10:24 PM, Henrique de Moraes Holschuh < h...@debian.org> wrote: > 1) make it clearn that static linking is to be used only when strongly > justified (e.g. system rescue tools like sash). > > As I see it, static libraries are mostly meant for the end-user, not for distribution packages. E. g. my package witty (http://www.webtoolkit.eu) is a C++ web library (something like Rails, Django or Laravel). It is mostly used either in embedded (e. g. medical devices, routers, etc) or in high-load applications (e. g. a Facebook app). For the first use case I provide static libraries, for the second use case I provide shared libraries. One problem my users find is many libraries in Debian do not provide a static library, rendering my static libraries useless. -- Pau Garcia i Quiles http://www.elpauer.org
Re: version format for git snapshot
On Tue, Sep 15, 2015 at 1:24 AM, Colin Watson wrote: > > This is what I generally do: last release + "git" + ISO 8601 date and > time > > + 10-char substring of the commit id. I. e: > > > > 0.5+git20150531T211420-cdd9d98f2c-1 > > IME it is in fact useful to have version numbers that stand a chance of > fitting in people's short-term memory. > > That's definitely an advantage of your schema over my schema. The idea of having the commit id in the version string was to make versions (easily) machine processable. But if one is not going to release more than one snapshot a day (and I guess very few people do -- I rarely do!), then it's something to consider, definitely. Hmmm I'll have to think what to do next time I'm going to package snapshots! :-) Thank you for sharing! -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
On Monday, September 14, 2015, Jonas Smedegaard wrote: Makes perfect sense to me to add only the date for snapshot releases - > both revision control system and commit id is irrelevant in version > string - those belong (if at all) in changelog along with release > nickname and whether release coincided with your birthday. > > I will use this scheme from now on: > > 0.4+20150911 > > What if you take a second snapshot on that day? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 11:04 AM, Jakub Wilk wrote: * Pau Garcia i Quiles , 2015-09-14, 10:46: > >> 0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1 >> > > Still shorter than 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1. > You're not trying hard enough. Oh well, I'm just trying to get all the required information with minimal verboseness :-) You don't need the full commit id, 10 chars is usually more than enough in a repository -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 8:51 AM, Colin Watson wrote:
On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote:
> > How would you format the upstream part of the packages version number?
> How
> > about 0.4+24+git+a5e5f9e?
>
> I wouldn't put the commit identifier in the package version at all. It
> isn't sortable, so clearly doesn't belong in a version string; it can be
> documented in the changelog instead. I'd put a date in the version.
>
The problem with date is searching in git log is difficult.
This is what I generally do: last release + "git" + ISO 8601 date and time
+ 10-char substring of the commit id. I. e:
0.5+git20150531T211420-cdd9d98f2c-1
It includes all the information:
- Last release (0.5)
- It's screaming "I'm a git snapshot!" ("git")
- It's sortable thanks to the ISO 8601 date *and* time (20150531T211420)
- Commit id, for easier search in git log, git describe, etc (cdd9d98f2c)
- Debian packaging version (1)
- It's consistent: it's always the same regex, with no room for optional
fields
Using the time is required, otherwise if there are two snapshots in one
day, they may get the wrong sorting order due to the git commit id.
Do you think it's ugly? Wait to see what it gets to when I upload packages
to my Ubuntu PPA :-)
0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1
IMHO it'd be great if we could standardize on something, not matter what it
is.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Re: Summary of the DebConf firmware discussion
On Fri, Aug 28, 2015 at 5:33 PM, Steve McIntyre wrote: > 3. Advertise the "unofficial" firmware-included media better? > - > > Yes. > > It was generally agreed that this would be a good thing. Alongside the > links to normal media in various places on our web sites, we should > include links to the non-free media too, *with* some explanatory text > describing the problems with non-free firmware and why it's not > included by default. Also, similar better links to the firmware > bundles will help. > > Let's see if I understood this correctly (1) The official images do not contain non-free stuff, such as firmware, therefore those images are useless for many users these days (2) Therefore, we also officially generate unofficial images which do contain non-free stuff, such as firmware, therefore those images are sueful for many users these days As a result of (2), the are officially advertising unofficial images that were officially generated Looks a bit crazy to me I wasn't at DebConf but here is another idea, probably quite similar to the firmware bundles (which I didn't know of, either): - Have the official image, without non-free stuff. Usable and useful to those who have sufficiently free hardware. - Have the bundles as tar.gz and also as ISOs. Advertise them along with the installer ISOs: "here you have the non-free stuff you may need to enable some hardware features" - When the installer starts, give the user the choice to use non-free stuff. Maybe include a link to FSF or Debian or whatever explaining why some vendors are evil. - Offer to download from the Internet (if a network connection is available) or use a second ISO/USB. - Do this no matter what hardware is available. E. g. many Broadcom wifi chipsets provide Bluetooth too but Bluetooth and some advanced wireless stuff (for instance, 802.11ac) will only work after loading the proprietary firmware. I think Ubuntu is doing something in that line? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Security concerns with minified javascript code
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère wrote: Vincent Bernat wrote: > > (...) > > It has already been said numerous time in the past, for some Javascript > > code, we don't really have the tools in Debian to easily go from the > > source to the minified version. It's possible, but without the > > appropriate tools, it's painful. > > I've been using yui-compressor to get the minified javascript. > > I never add any issue this it. > > Now if you are talking about generating one big javascript file > containing different fragments in the correct order, that's another > story. But that last issue is not really related to minified js. You can > compress the javascript either before or after yui. > > I have experienced trouble with minifying JavaScript code in my package witty. Upstream uses uglifyjs to minify, so do I where it's available. But on some platforms, uglifyjs is not available due to missing nodejs (which is in turn due to missing V8 on some platforms). That forces me to use yui-compressor, which is untested by upstream, and may introduce hard-to-find bugs: https://sources.debian.net/src/witty/3.3.4%2Bdfsg-2/debian/rules/ ### JavaScript minifier# Use UglifyJS (what upstream uses) where available,# yui-compressor (what upstream used in the past) where there is no UglifyJSMINIFIER=$(shell which uglifyjs)ifneq ($(MINIFIER),) IS_UGLIFY2=$(shell grep -E '"version": "2\.[0-9]+\.[0-9]+"' /usr/lib/nodejs/uglify-js/package.json) ifeq ($(IS_UGLIFY2),)# Legacy: uglifyjs < 2.xMINIFIER_FLAGS=-c --no-seqs -nc else# uglifyjs >= 2.x MINIFIER_FLAGS=-c sequences=false endifelse MINIFIER=/usr/bin/yui-compressor MINIFIER_FLAGS=--nomungeendif -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Security concerns with minified javascript code
On Fri, Aug 28, 2015 at 4:12 PM, Jean-Michel Vourgère wrote: Vincent Bernat wrote: > > (...) > > It has already been said numerous time in the past, for some Javascript > > code, we don't really have the tools in Debian to easily go from the > > source to the minified version. It's possible, but without the > > appropriate tools, it's painful. > > I've been using yui-compressor to get the minified javascript. > > I never add any issue this it. > > Now if you are talking about generating one big javascript file > containing different fragments in the correct order, that's another > story. But that last issue is not really related to minified js. You can > compress the javascript either before or after yui. > > I have experienced trouble with minifying JavaScript code in my package witty. Upstream uses uglifyjs to minify, so do I where it's available. But on some platforms, uglifyjs is not available due to missing nodejs (which is in turn due to missing V8 on some platforms). That forces me to use yui-compressor, which is untested by upstream, and may introduce hard-to-find bugs: https://sources.debian.net/src/witty/3.3.4%2Bdfsg-2/debian/rules/ ### JavaScript minifier# Use UglifyJS (what upstream uses) where available,# yui-compressor (what upstream used in the past) where there is no UglifyJSMINIFIER=$(shell which uglifyjs)ifneq ($(MINIFIER),) IS_UGLIFY2=$(shell grep -E '"version": "2\.[0-9]+\.[0-9]+"' /usr/lib/nodejs/uglify-js/package.json) ifeq ($(IS_UGLIFY2),)# Legacy: uglifyjs < 2.xMINIFIER_FLAGS=-c --no-seqs -nc else# uglifyjs >= 2.x MINIFIER_FLAGS=-c sequences=false endifelse MINIFIER=/usr/bin/yui-compressor MINIFIER_FLAGS=--nomungeendif -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Enable external repository on package installation
Hello, I am the maintainer of witty, a C++ library for web development. In addition to the latest version of Debian, I provide backports of the package for all the supported versions of Ubuntu in a PPA, and for Debian oldstable in an OBS repository. I have been doing this for years. So far, people find about this repositories in the Wt website. Many Ubuntu users do enable it. I was wondering if it would be acceptable to add a debconf question to the official package. Something like: "Do you want to enable an external repository which will provide you with the latest version of Wt? This repository is maintained by the official Debian/Ubuntu maintainer but it is not endorsed or supported by Debian/Ubuntu." Answering "yes" would install a /etc/apt/sources.list.d/wt.list file. Is this acceptable? Has anyone ever done this and can talk about his experience? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George wrote: > The only option is to make sure the users do not suffer from the fork, by > making sure they can easily use the version that is most suited for their > need without being sucked into the developers' disagreements. > Can we get back on topic? With or without libav in Debian, there are solid technical reasons to have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although they parted ways in a civilized way: different library names), and we certainly have a ton of librarys which provide very similar features. Since before the fork, the libav developers have been sabotaging ffmpeg as much as possible, in every "combat field": library names, library versions, taking distributions hostage (ffmpeg package that installs libav!?), etc. This is not the way to fork anything. This is a fact. I don't care whether Michael Nidermayer was a dictator or not. I don't care whether the code-review rules in libav are better or worse. I don't care what the Linux kernel does. The only thing I care about is Debian is shipping a less-capable (i. e. less multimedia formats supported) distribution due to this conflict. This has to stop. ffmpeg is not yet in Debian due to the filename clashing, which will most certainly cause binary problems. If libav and ffmpeg maintainers cannot reach an agreement regarding library names and it's not possible to simply use either ffmpeg or libav indistinctly due missing features binary compatibility, etc, the obvious solution is that BOTH libav and ffmpeg rename their libraries in Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done in the past. And before someone mentions it: I don't think it's too late. It's getting too late because nobody with the right to act is doing anything. In the end, our users are the ones being harmed and we are left wondering why they are increasingly moving to other distributions or Mac OS X. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 1, 2014 at 1:29 AM, Russ Allbery wrote: > I personally don't have enough information to know why libav was chosen > instead of FFmpeg, and the discussion on debian-devel so far has mostly > come from FFmpeg advocates. So there's probably another side to the story > that hasn't been stated here yet. > libav was not chosen in Debian ffmpeg had a leadership crisis a few years ago: Michael Niedermaier (who has written here) was accused of dictatorial methods by some ffmpeg developers. I don't know if they were right or not in their complains and frankly, I don't care. Those guys tried a coup d'etat, stealing the domain, name, code repository, logo and everything and leaving Michael out. When Michael was able to recover control of some things, and get a new hosting, source repository, etc, they forked ffmpeg in libav. The libav guys knowingly tried and still try to break ffmpeg by using the same library names and for a long time, version numbers too. The Debian maintainer of ffmpeg at the time (Reinhard, who has written here too) was one of the guys who took the libav side instead of the ffmpeg side. He used the ffmpeg package names to provide libav, and actively blocked any effort that would lead to src:ffmpeg being actual ffmpeg.org. That's why we have libav now instead of ffmpeg. I'm all for forks but if you do a fork, at least you do it with ethics: different library names, sonames, etc. The libav developers have tried from minute zero to create a conflict. And what has been the outcome of that? A library which worse than ffmpeg in features, codec support, security, and essentially everything. As someone mentioned way back in the thread, the only people who seem to prefer libav over ffmpeg are the libav developers. I am not involved in libav or ffmpeg and if libav would be better technically, in security, etc, I would be all for libav, even with all the ill-intented methods they used. But it's not the case: they disrupt peaceful open source communities (see this discussion, it's not the first time in Debian and it has happened in other distributions too) with what goal?... forcing a worse library in technical regards? OMG. Pointless. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 1, 2014 at 12:41 AM, Russ Allbery wrote: > How is it better to have libav, which does a lot less security > > bugfixing, in? > > It's not. > > However, what was proposed was having *both* of them, not dropping libav > in favor of FFmpeg. > So had the proposal been "hey, let's replace libav with ffmpeg", would you vote "yes" ? Only one library to maintain and review, and it happens to have good upstream support And replacing libav with ffmpeg is easy and the ffmpeg maintainer is committed to help port reverse dependencies. Looks good to me. Maybe Andreas should have made a not-so-polite proposal? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette wrote: > No FFmpeg security update is “minor”. > > Almost each ffmpeg security bug is a code execution one. Almost each and > every one of them is hard to backport. > > Those 10 security updates might represent more work than 100 *really* > minor security updates. > How is it better to have libav, which does a lot less security bugfixing, in? I'd rather have a library that fixes bugs than one that passes in order to look "more secure". When in fact it's less. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, Jul 29, 2014 at 6:10 PM, Andreas Cadhalpun < andreas.cadhal...@googlemail.com> wrote: > I don't have an opinion about ffmpeg vs libav, apart from how hard the >> soname transitions are, especially in ubuntu where we somehow ended up >> with ex-multimedia packages around that either never were in debian, >> or have been long removed from testing and/or unstable. >> > > There are only 6 additional reverse-build-dependencies of src:libav in > utopic. Two build against lib*-ffmpeg-dev without further changes, one > needs a simple patch to use pkg-config, one needs a patch to adapt to newer > API (also needed for Libav 10), one is BD-uninstallable and one fails for > unrelated reasons, but its build-dependencies on libav*-dev seem to be > unnecessary anyway. > > Per package list: > > alsa-plugins-extra: OK > bombono-dvd: PATCH CodecID > dvdstyler: Unmet build dependencies: libwxsvg-dev (>= 2:1.0.9) > gstreamer-vaapi: error: unsupported GStreamer API version 1.4 > kffmpegthumbnailer: OK > libdlna: PATCH pkg-config > In addition to this, I would like to note there is a lot of closed-source software which uses ffmpeg instead of libav. Not saying it doesn't exist but I don't know a single piece of closed-source software which has moved from ffmpeg to libav. I know, I know "non DFSG-free software, we don't care". Well, I do. E. g. I'm having trouble with Qt right now because I'm using the commercial SDK which indirectly uses ffmpeg to provide some codecs on Linux. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Unreleased libraries
On Fri, Feb 7, 2014 at 5:52 PM, Andreas Beckmann wrote: > If your upstream is git, you don't have monotonically increasing > revision numbers, but (unordered) commit hashes. I usually use something > based on 'git describe' as that gives you a number of commits since a > reference tag in addition to a release. > > E.g. git describe returns 0.56-24-gffe37cd which is > --g > and I would version the snapshot as 0.56+git24-gffe37cd. > > For git-based projects, I usually use a timestamp + commit id, e. g. 0.56+git201402061828-gffe37cd. Slightly longer but easier to understand and sorts as expected. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Unreleased libraries
On Fri, Feb 7, 2014 at 5:41 PM, Michael Shuler wrote: > Is there a policy on how to package software that does not make releases? >> > > A version similar to skia_0.0-1~svnr1234 would allow an upstream version > of i.e. 0.1 (if they ever release) to supersede your packaged version. It > should also allow you to upgrade via new svn version (0.0-1~svnr1235), as > well as new packaging of same svn version (0.0-2~svnr1234). Please, > correct me, if there is a better method, here! > > That's exactly what I had thought: 0.0-somenumber~svn123, where "somenumber" is the soversion. Runtime packager for each soversion in other to allow coinstallation, development packages, etc. I have also noticed Firefox includes Skia in its source package, although it may be justified because they heavily patch Skia. Icedove (Thunderbird) and XULRunner also include their own version of Skia. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Unreleased libraries
Hello, I am interested in packaging Skia ( https://code.google.com/p/skia/ ), the 2D library used in Chromium, Firefox and others. I need it because a package I maintain (witty) is replacing GraphicsMagick with Skia. I went to Skia's download page and... found there is none: Skia does not make releases, tags, or anything like that. You download from Subversion and the svn revision is all you have. Is there a policy on how to package software that does not make releases? http://en.wikipedia.org/wiki/Skia_Graphics_Engine https://code.google.com/p/skia/ Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: MiniDebConf 2014 Barcelona Call for Proposals
On Fri, Dec 27, 2013 at 10:58 PM, Mònica Ramírez wrote: === > MiniDebConf 2014 Barcelona Call for Proposals > === > > Debian Women is proud to announce that it will hold a MiniDebConf > in Barcelona on 15-16 March 2014, where Debian enthusiasts from > far and wide will gather to talk about the latest Debian changes > and the Debian community, as well as to meet new and old friends. > [...] Is this conference limited to women only? (it's not clear from the CfP or the website) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#732159: Should this package be removed?
On Sat, Dec 14, 2013 at 11:53 PM, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Well, to be honest, I think the problem is actually libav, not mplayer. > Most users prefer the original ffmpeg over libav from my own experience. > Agreed Furthermore, I still do not understand why libav to take over the name ffmpeg in the archive -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
FOSDEM 2014 Desktops DevRoom Call for Talks
Hello, We are inviting talks for the Desktops DevRoom at FOSDEM 2014, which will take place in Brussels (Belgium) 1-2 February 2014. The Call for Talks is here: http://www.elpauer.org/2013/10/fosdem-desktops-devroom-2014-call-for-talks/ The change of the default desktop in Debian from Gnome to XFCE could be an interesting talk, BTW. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Proposal: switch default desktop to xfce
On Fri, Oct 25, 2013 at 12:50 PM, Andrey Rahmatullin wrote: > > Why are we still talking about CDs? Didn't everybody move to DVDs a > century > > ago? > And then they moved away from DVDs too. > I guess we are talking about install images to download (where you usually > don't want to download entire DVD1), not about ISOs to actually burn. > In that case, enhancing jigdo so that the user can create and download a customized install image would IMHO be more useful than deciding which desktop becomes/remains default. Maybe a web version would help too: you choose what (broad) features you want in the install image, dependencies are automagically added, install image is generated and downloaded. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Proposal: switch default desktop to xfce
On Thu, Oct 24, 2013 at 6:52 PM, Andrei POPESCU wrote: Would LXDE still fit on the same CD? I'm guessing yes, but I'd rather > have it explicit. > Why are we still talking about CDs? Didn't everybody move to DVDs a century ago? People who want to install Debian on old machines which only have a CD reader can use USB or an external DVD unit and let the project move to DVDs. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Wed, Aug 28, 2013 at 4:55 PM, Neil McGovern wrote: > I think you have a very valid point here. I kind of doubt many people > would > > like to run on a five year old desktop. > > > > Stats seem to disagree: > > http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=11&qpcustomb=0 Five year old desktop doesn't matter as long as you can install recent applications. That's not a problem on Windows or Mac, and it's not a problem on Linux (or any other Unix) either thanks to RPATH/RUNPATH with $ORIGIN . -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 7:18 PM, Russ Allbery wrote: > IMHO the Security Team should not act as fixers themselves but more as > > proxies, passing information about a security issue to the maintainer of > > the package. > > And what happens then if the maintainer doesn't respond? > > Then, and only then, as a last resort, the Security Team / LTS Team takes care of the problem -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 12:03 PM, Lars Wirzenius wrote: On Tue, Aug 27, 2013 at 11:53:47AM +0200, Pau Garcia i Quiles wrote: > > But I'd like to stress we need *all* developers to be involved fix bugs > > (esp. security) in their packages in all the supported releases, not only > > in current-stable. > > I am afraid I am not on board for this. I do not agree with requiring > me to support old software for years and years after I've stopped using > it. It is not something that interests me as a technical challenge; > instead the task is tedious and boring. > (I don't want this to sound rude or smartass but genuinely interested because I'm surprised more DDs think like you, as I discovered in the DreamHost thread) What do you do with the 1 year of support Debian currently gives to oldstable? It's also 1 year you stopped using that version, so no technical challenge either. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 2:09 PM, Neil McGovern wrote: Indeed. Look at the security team for example. In theory, if all > maintainers cared enough about the older packages, we woudn't need the > level of people we currently do. > IMHO the Security Team should not act as fixers themselves but more as proxies, passing information about a security issue to the maintainer of the package. Maintainers are not always fully aware some old version of their package is affected by a security issue. OTOH, the Security Team is continually monitoring CVEs, etc. Or at least, that's how I'd like the Security Team to work. It would alleviate the burden on them and move the bugfixing/security fixing to the people who know the package better and are probably in touch with upstream. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 10:56 AM, Michael Meskes wrote: > > Guys, if you want it to happen, raise your hands *now* like Gustavo did. > > Otherwise, please everyone: let this thread die and never raise the > > topic again in this list. > > Raising my hand here ... > One more hand. But I'd like to stress we need *all* developers to be involved fix bugs (esp. security) in their packages in all the supported releases, not only in current-stable. Having a team of people like Mike, Michael, Gustavo, me, etc to take care of EVERY package is plain impossible, especially if we want 5 years support for the *whole* archive (IMHO Ubuntu did a smart move in regards to support when it split the archive in main/universe/multiverse and decided to support only main). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Wed, Aug 21, 2013 at 5:45 PM, Kevin Chadwick wrote: Does anyone even know for sure what the decision to switch was actually > based upon? > Not really, but I have seen Debian rejected at several companies (customers) due to too-short support of old releases and too-far away releases. Both are real problems, regardless of why DreamHost decided to give up on Debian. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Wed, Aug 21, 2013 at 1:48 AM, Ben Hutchings wrote: Ubuntu uses a combination of driver backports and newer kernel versions > in LTS releases. > > As Clint, Philipp and you say, I was wrong. However, I don't see that as an insurmountable argument against Debian LTSs. It "just" means the kernel and X/Wayland/nouveau/radeon teams need more people. Either that, or we "just" do not support new hardware for LTSs and let that to the vendor (not ideal but better have Debian LTS with no new hardware support than no Debian LTS, IMHO). The fact that I had never needed an LTS dot release made me think. I've been installing Ubuntu on servers and desktops since 4.10 at three companies and dozens of customers and never noticed/required a dot release for LTS: - On the desktop, it makes sense: we've almost always gone for the latest Ubuntu release, LTS or not (the only cases where we have used LTS for desktop was for military use and in that case the hardware was so old it was already old and well supported when LTS was released :-) ) - On the server, we always gone for very standard hardware and always installed the latest LTS. I guess the 2-year gap between LTSs is small enough to support newer hardware and the 5-year support term is big enough to justify the investment. Maybe we don't even need to make alternate Debian releases LTS but keep releasing every ~2 years and make every release a 5-year support LTS. Whatever we do, IMHO we need to do something. Debian is losing relevance as an "installation" release and it's becoming more and more an "upstream for distributions" (Ubuntu, Mint, etc), like SourceForge or GitHub are for us :-( -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 8:25 PM, Russ Allbery wrote: > >> The same people that maintain the packages in sid and stable: the > >> maintainer(s) for each package. [...] > > > That is not the case. At the moment most of this is done by the > > Debian security team. Of course some package maintainers do help. > > I consider it part of my responsibility as a package maintainer to provide > security support for my packages for as long as Debian does. If I felt > like I couldn't do that, I would orphan the package or look at having it > removed from Debian. I don't think there's any way that one team can > scale to providing security support for the entire archive; it's hard for > them to even track the existence of issues for the entire archive. > > That's exactly how I see it, glad to see I'm not alone :-) > My experience is that I can just barely manage to > convince upstreams to look over my backports of security patches to > packages in oldstable What makes you think Ubuntu, Red Hat, etc ask upstream to look at their security patches for old versions or even approve them? When I backport something, I send it to upstream as a courtesy, in case they want to release a patch version, not because I expect them to give me the OK -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 6:25 PM, Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:
> > The bigger problem for a Debian LTS is this: 1. who is going to do
> > > security support for it ?
> >
> > The same people that maintain the packages in sid and stable: the
> > maintainer(s) for each package. [...]
>
> That is not the case. At the moment most of this is done by the
> Debian security team. Of course some package maintainers do help.
>
>
IMHO that should be turned around: package maintainers should be the ones
responsible for updates and the Security Team should help with that (e. g.
by providing tips and/or reviewing the fixes)
> For orphaned packages, NMUs by other
> > developers or even a new maintainer team ("foster-car...@debian.org").
> > Providing fixes, security or not, is our part of our duty as Debian
> > developers. Sure, packaging new upstream versions is always more exciting
> > than fixing a broken version/package but it needs to be done.
>
> You seem to be saying "this is an important thing to do - will you
> all please go and do it".
>
>
Exactly. That's what I do for my packages (in fact I backport newer
versions of some of my packages to every Debian and Ubuntu which is still
supported).
> That's not how things work. In summary, unless and until we have
> people who volunteer to do the security support for an LTS, we won't
> have an LTS.
Maybe I'm wrong but I fail to see why "security support for LTS" should be
a different team than "security support for stable". To me, it should be
the same team, and maintainers and packages should be #1 in the list of
people to work on fixes, as I said above.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
> The bigger problem for a Debian LTS is this: 1. who is going to do
> security support for it ?
The same people that maintain the packages in sid and stable: the
maintainer(s) for each package. For orphaned packages, NMUs by other
developers or even a new maintainer team ("foster-car...@debian.org").
Providing fixes, security or not, is our part of our duty as Debian
developers. Sure, packaging new upstream versions is always more exciting
than fixing a broken version/package but it needs to be done.
> 2. How are we going to deal with
> drivers for new hardware - upgrade the kernel to LTS+1's ?
>
AFAIK Ubuntu does not add drivers for new hardware to any version save for,
maybe, some exceptional cases (that I cannot remember, frankly).
Quite the opposite: it's the hardware manufacturers themselves who are
compelled to provide drivers for RHEL, SLES and Ubuntu LTS due to customers
asking. That's why there is an option to "load drivers from disk" at the
very beginning of installation (isolinux prompt) on RHEL, SLES and Ubuntu.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Tue, Aug 20, 2013 at 12:46 PM, Steve Langasek wrote: > On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote: > > > Russ already replied and I agree with its reply. Just to say that > Debian > > > usually has a 3 year support. This is the kind of misguiding that I > > > usually hear when people promotes Ubuntu over Debian. > > > I know already that this isn't a popular idea, but another option > > would be to release less often. If releases were every 3 years, then > > the support window would be 4 years, which almost gets to the apparent > > sweet spot of 5. > > I think the more useful option would be for Debian to figure out how to > lengthen its security support window instead. > Agreed. I know many companies that see Ubuntu's non-LTS releases as release candidates with real-world testing and LTS's as stable releases. That's why Ubuntu is successful: when a company picks an LTS, they perceive it as something that has been properly stabilized (although often times it's not true, e. g. Mir in the next LTS). Maybe we should adopt a similar model: - Stable release every 12-18 months to avoid shipping rotten software - Alternate releases are LTS - LTS releases get 4-5 years support (to determine) - Non-LTS releases get 6 months support after the release of the next LTS version - LTS overlap in support for at least 1 year to give users ample time to move to the next LTS E. g: - In January 2014 we release Debian 8.0. We make this an LTS release, meaning it would get updates for, say 3 years (until January 2017), and security updates for 5 years (until January 2019). - In February 2015 we release Debian 9.0. Non-LTS release. It will get at least 1 year of support (because we won't release the next version until at least 1 year later) + 6 months - In April 2016 we release Debian 10.0. LTS release. It will get again 3 years of updates and 5 years of security updates. This means support for Debian 9.0 will end in October 2016 (LTS release date + 6 months) - ... -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Dreamhost dumps Debian
On Mon, Aug 19, 2013 at 9:34 PM, Vincent Bernat wrote: > ❦ 19 août 2013 21:04 CEST, jida...@jidanni.org : > > > > http://dreamhost.com/dreamscape/2013/06/03/change-is-in-the-air-dreamhost-upgrades/ > > Many people seem to justify a switch to Ubuntu LTS with the argument of > 5-year security support. This support only applies for packages in > main. A common example is nginx which is in universe. Packages in > universe are just unsupported. They may or may not get any security > support. If you need to advocate for Debian vs Ubuntu, I think this is a > strong argument. > The fact that Debian only supports stable releases for about 1 year after the release of the next version does not exactly help make a case against Ubuntu, even now that non-LTS get only 12 months (instead of the former 18 months) of support. Maybe longer support terms for stable versions of Debian would help (3 years?). Also, many advanced users of Ubuntu end up contacting the Debian packager for updates, fixes, backports, etc Even through Launchpad directly (the Debian maintainer is shown as the package maintainer and receives e-mail automatically) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
C++11
Hello, I am the maintainer of Wt [1], a C++ web development library (think of Qt or Gtk+ for the web) and web server. My upstream [2] sent me a mail asking about mixing C++03 and C++11. My understanding is it is not possible for a variety of reasons, unless all players take great care (see [3], for instance). The specific case upstream asked about is Boost.Signals2, which provides a different and ABI-incompatible implementation [4] depending on whether Boost was compiled as C++03 or C++11. I expect users and Wt to use more and more C++11, to the point where Wt may not even be compilable as C++03. Given that Wt depends on Boost, I can foresee a problem: - Application may be C++11 or C++03, depending on what the user is doing - Wt would be C++11-only - Boost would be compiled as C++03 in Debian - Wt (C++11) would depend on Boost (C++03), which but this mix is broken I'm talking about Wt + Boost in this e-mail but this will arise as other combinations for other packagers: log4cpp, Xerces, SOCI, ACE (which I co-maintain), Gtkmm, ZeroC ICE, POCO, etc I have googled but so far I have found no clear conclusion about this for Debian. What are we going to do with C++11? Are we goint to provide C++03 and C++11 using multiarch (is that even possible?) ? Everything C++11? Fingers crossed? E. g Microsoft took a very pragmatic decision: C++11 is enabled by default and it is not possible to disable it. [1] Wt - http://www.webtoolkit.eu [2] EmWeb - http://www.emweb.be [3] Thiago Macieira: C++11 use in Qt5: Challanges and Solutions - http://www.youtube.com/watch?v=olSSGA_nD1Q [4] http://lists.boost.org/Archives/boost/2013/05/203762.php <http://www.youtube.com/watch?v=olSSGA_nD1Q>-- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Reporting 1.2K crashes
Hello, Is it possible to use/download Mayhem from somewhere? On Tue, Jun 25, 2013 at 7:28 AM, Alexandre Rebert < alexandre.reb...@gmail.com> wrote: We found the bugs using Mayhem [1], an automatic bug finding system > that we've been developing in David Brumley's research lab for a > couple of years. We recently ran Mayhem on almost all ELF binaries of > Debian Wheezy (~23K binaries) [2], and it reported thousands of > crashes. > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: vision: easily move all my data and config to a new machine
On Sun, Jun 23, 2013 at 6:56 PM, Thomas Koch wrote: I'm currently switching my laptop (again) and I have the following vision: > The Debian system should provide tools to make it possible to switch over > from > one machine to another in a matter of minutes without leaving any data, > configuration or customization of the old machine behind. > http://tldp.org/HOWTO/Hard-Disk-Upgrade/ It just needs an update to the latest changes in FHS (/run, /sys, etc), replace LILO with grub, etc -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Fwd: Debian RT
Hello, What is the right way to contact the Security Team? I have tried the tracker, and a variety of e-mail addresses but nothing yet (maybe I'm doing something wrong?). An update to Debian 7 was released today without a security fix for my package jquery-jplayer, even though the fix has been available for one solid month :-/ -- Forwarded message -- From: Pau Garcia i Quiles Date: Fri, May 31, 2013 at 10:09 AM Subject: Fwd: Debian RT To: secur...@rt.debian.org Cc: secur...@debian.org, t...@security.debian.org, Vincent Bernat < ber...@debian.org> Hello, I have had no response for my security report in two weeks. Any news on allowing jquery-jplayer 2.1.0-3 in the security repository? Also, this is wrong: https://security-tracker.debian.org/tracker/CVE-2013-2023 ALL versions are vulnerable. The fix for stable is 2.1.0-3 (waiting for an answer from the Security Team) and the "fix" for testing/unstable is 2.3.4-1, which Vincent just sponsored. Thank you. -- Forwarded message ------ From: Pau Garcia i Quiles Date: Thu, May 16, 2013 at 6:22 PM Subject: Debian RT To: secur...@rt.debian.org Cc: Vincent Bernat Hello, A new XSS vulnerability was discovered in my package jquery-jplayer. Useful information (as listed in the DD Reference) : - Whether or not the bug is already public The bug is public and classified as CVE-2013-2023 - Which versions of the package are known to be affected by the bug. Check each version that is present in a supported Debian release, as well as testing and unstable Upstream versions 2.2.19 and newer are affected, including 2.3.0 Wheezy contains 2.1.0-2, which is upstream's 2.1.0 plus three backported security fixes Testing contains 2.1.0-2 too Sid contains 2.3.0-1, which is upstream's 2.3.0, unchanged. I am packaging upstream's 2.3.2 as 2.3.2-1 and it will be ready later today. - The nature of the fix, if any is available (patches are especially helpful) Backport of upstream's fixes - Any fixed packages that you have prepared yourself (send only the .diff.gz and .dsc files and read Section 5.8.5.4, “Preparing packages to address security issues” first) jquery-jplayer 2.1.0-3 contains the fixes. It is available from mentors: http://mentors.debian.net/debian/pool/main/j/jquery-jplayer/jquery-jplayer_2.1.0-3.dsc Debdiff to 2.1.0-2 attached - Any assistance you can provide to help with testing (exploits, regression testing, etc.) - Any information needed for the advisory (see Section 5.8.5.3, “Security Advisories”) Please check CVE-2013-2023 -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) jquery-jplayer_2.1.0-2_to_2.1.0-3.debdiff Description: Binary data
Re: Packaging releases without a tarball (sometimes)
On Fri, May 17, 2013 at 4:31 AM, Chow Loong Jin wrote: > On 17/05/2013 01:01, Pau Garcia i Quiles wrote: > > > > Patch releases are NOT available as zip files and the list of > wrongdoings is long: > > - Patch releases are only available from the git repository > c5fe17bb4459164bd59153b57248cf94b8867373 > Maybe I'm daft, but I can't seem to find any patch releases, actually. > Where are > they stored? > > They are in the git repository with no tags and no indication in the commit message, you have to read the diff. Upstream usually announces patch releases in the mailing list (without saying the commit id of the release) but sometimes they even forget :-( c2417972af1295be8dcc07470b0e3d25b0a77e0b is 2.3.2 (untagged) 8ccc429598d62eebe9f65a0a4e6fd406a123c8b4 is 2.3.1 (untagged) c1c7a4dfa63bb6684d3670202e4a65d400dfce86 is 2.3.0 (tagged) c5fe17bb4459164bd59153b57248cf94b8867373 is 2.2.23 (untagged) etc -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Packaging releases without a tarball (sometimes)
Hello, I am having trouble with my package jquery-jplayer (a JavaScript library with Flash fallback) and I would like to ask for advice on how to proceed Major and minor releases are available as zip files from the official website ( http://jplayer.org/download/ ) and they are tagged in the git repository ( https://github.com/happyworm/jPlayer ). Patch releases are NOT available as zip files and the list of wrongdoings is long: - Patch releases are only available from the git repository - There are no git tags for patch releases - There are no branches for different major/minor releases and patch releases: everything goes into master - Patch releases do not contain only fixes but they also usually contain new features - The commit message rarely contains a reference to "new patch release", I need to read the diffs to know what's going on - The file hierarchy and organization of the git repository are different to what you can find inside the zip file for major and minor releases - The git repository contains the compiled Flash files and image files (the source zip does not) I have tried to convince upstream to make zip files available for patch releases. No results. When packaging patch releases, I'm not really sure which approach I should take: 1) Take the latest major/minor release (e. g. 2.3.0) and add a big patch with all the changes till the patch release I am packaging (e. g. 2.3.2) Advantage: no changes required to the rules Problem: the .orig.tar.gz is still 2.3.0, therefore I cannot use 2.3.2-1 as the package version but resort to something as 2.3.0-2 and say "this is actually 2.3.2" in the changelog text 2) Package minor releases as non-tarball upstream by git export'ing and sanitizing the proper commit Advantage: I can use the right package version (2.3.2-1) Problem: the packaging (rules, watch, etc) is different for patch releases and for non-patch releases 3) Ignore upstream's zip files for major/minor releases and package all versions as non-tarball upstreams by git export'ing and sanitizing the proper commit/tag Advantage: always the same packaging, always the right version Problem: ignoring upstream's zip files (is this a real problem?) I cannot be the only one suffering from this kind of problems. What have others done in the past? Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#706605: ITP: macfanctld -- Fan control daemon for Apple MacBook computers
On Thu, May 2, 2013 at 6:02 PM, Thibaut Paumard wrote: > Questions: > - How will this affect the speed at which Ubuntu users can get updates? > - Should we keep macfanctld in launchpad/mactel repo? Or is there a > smarter way if Debian package it? What I do for Wt ( http://packages.debian.org/source/sid/witty ) is providing the latest version in Debian, which will later come to Ubuntu, but also I have: - an Ubuntu PPA ( https://launchpad.net/~pgquiles/+archive/wt ) where I provide the latest version of Wt for all the versions of Ubuntu Canonical still supports (currently: 10.04, 12.04, 12.10 and 13.04) - an OpenSuse Build Service repository ( http://redmine.webtoolkit.eu/projects/wt/wiki/Installing_Wt_on_Debian ) where I provide the latest version of Wt for the latest stable version of Debian Users who want stability use the packages from the official Debian/Ubuntu repository. Users who want to use the latest version use the packages from the Ubuntu PPA / OpenSuse Build Service This model has been working very well for me for years and users are happy. Sadly, there are no Debian PPAs and I'm forced to use the OpenSuse Build Service, which I don't really like (no dput, censored main archive, etc). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: jpeg8 vs jpeg-turbo
On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert < bill.allomb...@math.u-bordeaux1.fr> wrote: > So I do not think it is fair to restrict JPEG support in Debian to 1998 > image > processing technology. > > According to this mail by the Fedora KDE maintainer, ISO rejected the latest changes introduced by libjpeg8: http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html Why should Debian use a library which generates non-standard JPEG files? And it's even worse for libjpeg9, IIUC from that discussion in the Digikam mailing list. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Bug#602034: jpeg8 vs jpeg-turbo
Hello, The KDE maintainer in Fedora started an interesting discussion some time ago in Digikam's mailing list. There was input from the very IJG: http://mail.kde.org/pipermail/digikam-devel/2013-January/066206.html It boils down to "jpeg6-2 is the only important thing. Forget about jpeg8 and jpeg9, which bring incompatible changes". http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html FWIW, Arch and Gentoo also follow the policy that jpeg6-2 (and jpeg-turbo with 6-2 API/ABI) is the real deal. On Wed, Apr 24, 2013 at 1:48 PM, Mike Gabriel < mike.gabr...@das-netzwerkteam.de> wrote: > Hi Ondřej, > > I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW > [1]. > > On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote: > > Debian has already open ITP[3] #602034 for libjpeg-turbo, which >> support libjpeg62 API/ABI and also some important bits of libjpeg8. As >> libjpeg is one of the base libraries of the system, I think it might >> be a good idea to discuss this project wide. Also although I have an >> opinion (as you might have guessed from this email) that we should try >> to be aligned with other distributions and the reasoning for not going >> for , I will be happy with whatever result will end-up. >> > > In an IRC discussion in #debian-devel several weeks ago the consensus was: > the RT team (represented Julien) will probably not want two libjpeg > implementations in Debian. My first packaging approach aimed at having the > compat mode libraries available [2] and allow the user to install them as a > drop-in replacement for libjpeg8. > > The IRC discussion lead to the result that the compat packages are not > wanted in Debian, only the native TURBOjpeg ABI. I was asked to ping Bill > Allombert about his opinion to transition from libjpeg8 fully to > libjpeg8-turbo. @Bill: can you repeat your disposition here again? I guess > our earlier mailing was a private mail exchange. > > A. Add libjpeg-turbo to Debian archive (that's easy) >> > > Done. Waiting in NEW. Only containing libturbojpeg.so.1 > > B. Add required provides/alternatives for libjpeg62-dev and >> libjpeg8-dev (where API/ABI match) >> > > A packaging example can be seen in [1]. If the packages disappears from > the NEW queue, you can also obtain a libjpeg-turbo version with compat > packages provided here [3]. > > C. Decide which package should provide default libjpeg-dev library >> > > Last statement from Bill: libjpeg by IJG > > Greets, > Mike > > > [1] > http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-2.**html<http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-2.html> > [2] > http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-1.**html<http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html> > [3] > http://packages.x2go.org/**debian/pool/main/libj/libjpeg-**turbo/<http://packages.x2go.org/debian/pool/main/libj/libjpeg-turbo/> > > -- > > DAS-NETZWERKTEAM > mike gabriel, rothenstein 5, 24214 neudorf-bornstein > fon: +49 (1520) 1976 148 > > GnuPG Key ID 0x25771B31 > mail: mike.gabriel@das-netzwerkteam.**de, > http://das-netzwerkteam.de > > freeBusy: > https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-** > netzwerkteam.de.xfb<https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb> -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Linux Future
On Tue, Jan 22, 2013 at 3:05 PM, Josselin Mouette wrote: > Le mardi 22 janvier 2013 à 14:57 +0100, Svante Signell a écrit : > > Worthwhile to read, definitely. > > Yet full of misinformation, like the idea that using D-Bus makes a > service less scriptable (while the reality is a complete opposite), or > that configuration files are less human-readable than shell scripts. > I guess his point is session bus vs system bus. I have suffered myself services which offer some DBus calls only over the session bus, not the system bus, while my use case was exactly I needed to make those calls through the system bus for a variety of perfectly valid reasons. Had those services used a socket or pipe, which does not really care about session-available vs session-less, I wouldn't have had those problems. DBus definitely has its place but IMHO it's being used too much, everywhere, one could say it's fashionable. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Linux Future
Hello, This blogpost is months old but it makes some interesting reflections: http://www.pappp.net/?p=969 I wonder what's Debian position in regards to FLOS* vs Unix philosophy. Is there one, at all? (I can't remember reading one, my apologies if this was discussed and I have not noticed) * FLOS = FreeDesktop.org + Linux + we don't care about non-Linux, NOT Free Libre Open Source -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 11:43 PM, Ben Hutchings wrote: > I believe the regression (removal of support for firmware loading > during module loading) has been fixed. However, the udev developers > *knew in advance* that this would be a problem, reported such uses > of firmware loading as being driver bugs. They then went ahead and > changed udev even though the drivers had not all been updated (and it > was evidently not easy to do so in some cases). If the systemd/udev people continue with that attitude, I'm expecting Linus Torvalds to come with his super-simple, super-fast, super-minimal and super-brilliant udev replacement any minute now. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBokuor9JEyhVh0-4bn=6xoh693vcvy4wf-6xc0v7s5ez...@mail.gmail.com
Re: Minified javascript files
On Sat, Aug 25, 2012 at 12:09 PM, Stefano Zacchiroli wrote: > Another problem is that the DFSG-freeness of the material contained in a > (source) package is no longer a "local" property. If one day the package > containing the corresponding source vanishes from the archive, unrelated > packages, possibly many of them, will become RC-instabuggy. I'd say it's not a problem. If one day the package containing the corresponding source vanishes from the archive, the other package (witty, in my case) would not be buildable, as witty build-depends on libjs-jquery. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcbokv540myod_decwh5515t_ihk1mln2m6ixwn8biwptn...@mail.gmail.com
Re: Minified javascript files
On Wed, Aug 22, 2012 at 8:30 PM, Russ Allbery wrote: > I think the debate in this thread is about whether it makes sense to > require removing the minimized version from the upstream source when we > don't install that file or otherwise use it in the binary package (because > the binary package depends on the separately-packaged version of the same > Javascript library, which already has both the minimized and non-minimized > version and fully satisfies the DFSG). That's exactly the point IMHO, it's just one more useless file in upstream's tarball. While working today on Wt again, I've noticed if I were to repackage the upstream tarball to remove jquery.min.js, I would also remove the Doxygen-generated HTML apidox. After all, I'm also regenerating them, therefore to me it's just a few thousands of useless files in upstream's tarball. But what's FTP masters stance on this? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcbokskacx5v8eqjcgqoy9sn6sd76kkkge8cmpwq-64nxf...@mail.gmail.com
Re: Minified javascript files
On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson wrote: >> As for >> verification, having the source next to the minified version does not >> guarantee anything about the minified version, all the more that we >> don't have currently in Debian Wheezy a reliable minifier. > > That seems problematic -- so even if the source is shipped, there is no > way to re-build the minified file? It really depends on using exactly the same version of the same minifier with exactly the same parameters (which you may not know) and even then you cannot be sure, e. g. a minifier may use generate shortened variable names randomly. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBoku94n7aqPsw3AYTZu=i84drkT=yqp9ayw-enpyrgzf...@mail.gmail.com
Re: Minified javascript files
On Sat, Aug 18, 2012 at 8:06 PM, Jakub Wilk wrote: > * Pau Garcia i Quiles , 2012-08-17, 13:39: > >>> 3) Make a new source package containing every jQuery version existing in >>> the wild, then build depend on that. >> >> FTP Masters do not like that solution. > > Interesting. Do you have any evidence for that? I'll look for the mail (maybe my memory fails) but even if FTP Masters accept that as a solution, it looks insane to me: if every package which build-depends on jQuery needs to include the full jQuery source, why do we build-depend on jQuery at all? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBokvCF=juhfuad41dxmutbxjrbzhykwnlq+nkts_r+k5...@mail.gmail.com
Re: Minified javascript files
On Fri, Aug 17, 2012 at 9:50 PM, Sam Morris wrote: >>> > So yes, we have the problem for precompiled windows DLLs in a source >>> > package. >>> >>> Interesting, that issue seems rather common. Maybe a lintian check >>> could alarm packagers of this? >> http://lintian.debian.org/tags/source-contains-prebuilt-windows- > binary.html > > This includes: > > tcltrf (source) > * win/msvcrt.dll > > This is part of Windows. I don't expect Debian has been granted > permission to distribute it. :) Are you sure it's not wine's? http://source.winehq.org/WineAPI/msvcrt.html -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBoksqu9z4f_3d6bE_EsRL4fvP9xLUqvPYH1s6=weL03EU=q...@mail.gmail.com
Re: Minified javascript files
On Fri, Aug 17, 2012 at 2:37 PM, Didier 'OdyX' Raboud wrote: > Le vendredi, 17 août 2012 14.03:38, Raphael Hertzog a écrit : >> Maybe we should fix DFSG #2 to say “The program must include source code >> for all the files that gets installed in the Debian binary packages [...]“. > > With this modification, upstream might then include (distributable) win32 > executables (or whatever else) in their upstream tarballs and have them > distributed by the Debian mirrors network without us taking a close look at > them? The modification to DFSG #2 that Raphaël proposes is indeed not good but I'd say this one would clear the issues: "The program ust include source code for all the files that are used in building the Debian binary packages" Which means: - If upstream is including jquery.min.js but I'm not using it because I'm using libjs-jquery, I don't need to repack the source tarball - If upstream is including a a Win32 DLL but I'm not using it for anything, I don't need to repack the source tarball etc -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcbokv+hnafhtjkv2c7xtqgbeq2l8lcjk1fzqeozk6fhsk...@mail.gmail.com
Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)
On Fri, Aug 17, 2012 at 1:08 PM, Andreas Tille wrote: > On Fri, Aug 17, 2012 at 12:26:49PM +0200, Mike Hommey wrote: >> > > > As an unrelated idea which popped up when reading this: Do you think >> > > > it >> > > > would be a sensible enhancement to uupdate if it could deal with a list >> > > > of files (wildcard strings that could be feed to `rm -rf`) which should >> > > > be removed from the upstream tarball? This could simplify repackaging >> > > > to a certain amount. >> > > >> > > I use a script for this: >> > > [...] > >> > I'm using a more sophisticated script, that allows to filter at the same >> > time as the file is downloaded, without actually extracting to disk. [...] It's not a matter of using a better or worse script, having dpkg, or uupdate, or some other tool do that for us. It's a matter of repackaging. It's a matter of altering upstream's package for (IMHO) no good reason. It's a matter of breaking user confidence: users are no longer able to compare Debian's .orig.tar.gz with upstream's tarball, or with Gentoo's traball, or with Fedora's tarball, etc just because we are shipping a different source tarball. I can understand repackaging when there are licensing issues, copyright issues, etc (music files, unlicensed artwork, etc) but for jQuery's minified JavaScript file, which is distributed under full compliance with jQuery's license and we have the full source (un-mininified) and the package build-depends on libjs-jquery and the package does not use the minified file at all? Give me a break. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBoktL5JJJVs=o450q9unv5sma7-nlvzde67etwrflwz7...@mail.gmail.com
Re: Minified javascript files
On Fri, Aug 17, 2012 at 1:14 PM, Jakub Wilk wrote: > 3) Make a new source package containing every jQuery version existing in the > wild, then build depend on that. FTP Masters do not like that solution. Vincent's question was due to FTP masters complaining about the package 'witty', which I maintain and he sponsors. http://packages.qa.debian.org/w/witty.html Witty does build-depend on libjs-jquery (it has for a long time, way before FTP masters expressed any concern), then minifies it, and symlinks it. But FTP Masters say the jquery.min.js must be removed from witty.orig.tar.gz because the non-minified version is not included. Given that I'm not using upstream's jquery.min.js at all, I wonder why I should repackage the source package. How is an unused jquery.min.js in the original tarball different from any other unused file (a picture, a README, or anything?) The users is not expected to modify jquery.min.js ever, if he wants to rebuild the binaries for witty, he is expected to modify libjs-jquery. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBokuzz_iZK9qOhLgW=x+mh02gr7jydsrusp34u6vtl4j...@mail.gmail.com
Re: [Pkg-javascript-devel] Node.js and it's future in debian
On Fri, May 4, 2012 at 6:53 PM, Steve Langasek wrote: > Hi Pau, > > On Fri, May 04, 2012 at 04:24:21PM +0200, Pau Garcia i Quiles wrote: >> Regarding the often-mentioned "many users run 'node script' from the >> command-line"... so what? If we can get enough distributions (Debian, >> Suse, Fedora, MacPorts and brew would likely be enough) to rename the >> node.js binary, upstream will be forced to change from /usr/bin/node >> to /usr/bin/nodejs > > Compare this with ruby, where the outcome of Debian diverging from upstream > was that the large and vocal upstream community shouted from the rooftops > that our packages were broken and should never be used, until eventually > (AIUI) Debian backed down. > > Engaging in brinksmanship with the upstream on such matters is not always > going to give a favorable outcome, even if we have other distribution > maintainers on our side; and in the meantime it's always unpleasant for the > users caught in the middle. Agreed. That's why my proposal was that *all* of those (Debian, Fedora, Suse, MacPorts and brew) did the rename, not just us (Debian). It's certainly not nice to push upstream to do something they don't want to do, but when upstream is not doing their due diligence... -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcbokuood1rwryptjlcocc4n2gdgswrox-qzteczxyu6hg...@mail.gmail.com
Re: Node.js and it's future in debian
Hi, What are other distributions doing? I've check and OpenSuse apparently lives happy with having /usr/sbin/node for axnode and /usr/bin/node for node.js. Has anyone contacted them about this? Regarding the often-mentioned "many users run 'node script' from the command-line"... so what? If we can get enough distributions (Debian, Suse, Fedora, MacPorts and brew would likely be enough) to rename the node.js binary, upstream will be forced to change from /usr/bin/node to /usr/bin/nodejs If this were some desktop application, I'd have doubts, but axnode being a daemon which runs on remote locations which may become isolated after a rename just because the JavaScript toolkit of the week decided to use a very generic name... sorry but no, does not look good to me. On Sat, Apr 28, 2012 at 3:31 AM, Carl Fürstenberg wrote: > Hello, > > There has been an log struggle between the nodejs package and the node > package, which is still unresolved (bug #611698 for example) And I > wonder now what the future should look like. > > To summarize the problem: > * the nodejs upstream binary is called "node", and the upstream > developers have refused to change it's binary name to nodejs for > debian; > * The the hamradio package "node" shipping a binary called "node", and > as it's so old, the developers argue that the package must ship a > binary called "node" or breakage will occur. > * The reason the nodejs developers want to ship the binary as "node" > is because all programs written for nodejs all has /usr/bin/node in > it's shebang > * the nodejs package are not allowed to conflict on the node package > just because the binary name is the same > > As I'm not a hamradio user, I'm off course biased towards letting > nodejs having the "node" binary and let it pass to testing. But we > must find a solution to this, as nodejs is getting more and more used, > and developers are forced to install nodejs from source to be able to > use it instead of install it via the package manager. > > Regards, > > Carl Fürstenberg > > > -- > 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/cacxjfdh5zyth6q-zdldafqneczbf3bqagrcahsaipenapbi...@mail.gmail.com > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcboks4k3bwngdae+x8yfz0s6rgqykof_jhg0+mttrtgwj...@mail.gmail.com
Re: The mingw* mess in Debian
On Thu, Nov 10, 2011 at 8:16 PM, Stephen Kitt wrote: > I've thought > about splitting the packages up, with separate 32- and 64-bit targets, but > I'm not sure whether replacing and providing the mingw32 packages would be > correct, since mingw-w64 isn't a drop-in replacement (the triplets are > different). If that's not a problem then why not! The names for the 32-bit > packages would probably be quite weird though since the upstream name is > mingw-w64 (and I'd rather keep that in the package names...). mingw-w64-i386 and mingw-w64-x64 are a bit ugly but still look sensible -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcbokvd1_r62r00tshpnbo4reakksqwq2zz61mb-umlhf5...@mail.gmail.com
Re: The mingw* mess in Debian
On Thu, Nov 10, 2011 at 9:28 AM, Fabian Greffrath wrote: > Am 09.11.2011 17:04, schrieb Pau Garcia i Quiles: >> >> Yes, that would be my advice. Unfortunately mingw32 is now too far >> behind mingw-w64. The fork has become better than the original >> project. > > I still love it for the MSYS bundle, though. You can use MSYS with mingw-w64, nuwen, tdm, or any other flavor of MinGW. For instance: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcboktznnwcvcyiacz+qynrc+a4_wfyuo_crabfd__0hzb...@mail.gmail.com
Re: Re: The mingw* mess in Debian
On Wed, Nov 9, 2011 at 5:04 PM, Fabian Greffrath wrote: > So if I understand it correctly, it would be best to entirely drop mingw32, > gcc-mingw32, mingw32-runtime and the other members of that family from > Debian and concentrate on mingw-w64 (which then, as a bonus, could be split > into packages targeting i686-w64-mingw32 and x86_64-w64-mingw32). Right? Yes, that would be my advice. Unfortunately mingw32 is now too far behind mingw-w64. The fork has become better than the original project. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBoktzgMJDO5HDkddGSQ=hHD=5f_wung4+-dwifijquir...@mail.gmail.com
Re: The mingw* mess in Debian
On Wed, Nov 9, 2011 at 2:16 PM, Simon McVittie wrote: > Does mingw[32] have any particular advantages over mingw-w64, I wonder? Not that I know. mingw-w64's CRT is more complete (it includes LFS, which mingw32 does not, for instance), includes more up-to-date compilers and handles threading better. Back then there were some concerns about mingw-w64 reverse engineering/clean room practices, but they were not justified and have been fully cleared. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcbokubotjvetddw-a2lz6gwlr1fxi4ban3+gpg2dsomtr...@mail.gmail.com
Re: The mingw* mess in Debian
Hi, It's even more complex than that, actually: mingw32 contains gcc 4.2.1 for 32-bit targets gcc-mingw32 contains gcc 4.4.4 for 32-bit targets. IIRC is not an official mingw.org release, this may be the reason why there is mingw32 and gcc-mingw32. gcc-mingw-w64 contains gcc 4.6 for both 32-bit and 64-bit targets. IMHO it would be better if it were split in two packages, one for 32-bit targets and the other for 64-bit targets. On Wed, Nov 9, 2011 at 1:33 PM, Fabian Greffrath wrote: > Dear -devel, > > is there a reason why we have both a mingw32 and a gcc-mingw32 package in > Debian? Both seem to contain the same, i.e. the GCC from the MinGW project > (please note they dropped the "32" for a while), but the version in > gcc-mingw32 is newer than the one in mingw32. > > For the 64-bit variant, there is a meta-package called mingw-w64 that pulls > in gcc-mingw-w64 and mingw-w64-dev. However, for the 32-bit variant, the > mingw32 package is not a meta-package but (an ancient version) the actual > compiler, as stated above. > > Then, some the package names are also inconsistent, compare mingw32-binutils > and binutils-mingw-w64. > > Is there a principle behind all this or where can I help to clean this up? > ;) > > Cheers, > Fabian > > > -- > 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/4eba730a.7060...@greffrath.com > > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBoku2=iWAgStH=ncvi8igxhhdcir+zehmfddttp4_hzy...@mail.gmail.com
Re: Dealing with embedded javascript libraries
On Thu, Oct 27, 2011 at 1:28 AM, Ian Jackson wrote: > The difficulty is that if we end up with ten different versions of > some random javascript library, when it turns out to have a security > vulnerability we need to somehow backport the patch to each of those > ten versions. > > And here "we" means the security team, not the people who uploaded the > ten versions in the first place. > > So this is rather unpalatable. What's the alternative? It seems that we only have two choices: - Either all packages use the same version of the JavaScript library (what we have been doing until now, which results in some packages not working properly due to changes in the JavaScript library that manifest only in some situations in runtime). This is essentially what we do with C, C++, etc libraries, btw: the whole Debian is built against the same zlib, same glibc, same libpng, etc or - Each package works with the upstream-bundled version of the JavaScript library (and then we have the problem of backporting security fixes). The advantage being we are sure the application works as expected because it has been tested by upstream. I'm not sure what's worse: a malfunctioning application or an insecure one. Zygmunt's proposal of adding unit testing, etc to upstream is a noble one but highly unrealistic, IMHO. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcbokuijju-o_w1vtmx0ayruqsz9cheucoslf3tsb3fjwx...@mail.gmail.com
Re: Minified files and source code requirement
On Thu, Oct 27, 2011 at 11:34 AM, Zygmunt Krynicki wrote: > W dniu 27.10.2011 11:22, Pau Garcia i Quiles pisze: > >> I said this in the original thread and I'll repeat it here: if we have >> the non-minified JavaScript, then I see no problem in providing only >> the minified version in the binary package. > > I'd like to twist this to a different viewpoint. For me as a developer > having -dev packages with non-minified version would be an awesome > improvement. Assuming I'm already using the lijs* packages for my work I > could simply install the -dev packages and flip a switch to use non-minified > versions and debug my application better. Mmmm interesting, I had not thought about -dev packages. I was talking about runtime packages all the time. The main "problem" I see is for many JavaScript libraries the minified version has a different name (jsquery.min.js vs jquery.js). This would be easily solvable by using symlinks in most cases, although it is additional work for the package maintainer. (in the case of witty, it is not solvable: a C++ file is generated from the JavaScript source when building, and there is no .js file to replace on runtime). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/cakcboksvwrrkqlwzmyoh_cxpratzzffsotkjso88h2-owcp...@mail.gmail.com
Re: Minified files and source code requirement
On Thu, Oct 27, 2011 at 10:47 AM, Roland Mas wrote: >> Requiring the non-minified file to be provided in the same source >> package is not a very productive use of our time. > > Right. In the same way that providing the source for our binaries > isn't very productive, I guess, because who's going to use it when they > have the pre-built binaries? I know this is an exaggeration, but > there's no substantial difference between the two cases. But we provide *source packages*. We do not provide the source in the *binary* package. That's what Raphael is talking about: having the minified and the original (non-minified) JavaScript in the *same* package (which would be the binary package, and also the source package). I said this in the original thread and I'll repeat it here: if we have the non-minified JavaScript, then I see no problem in providing only the minified version in the binary package. To me, these are equivalents: Minified Javascript == ELF binaries Original (non-minified) Javascript == C++ source code And that's not entirely true, btw, because it depends on what minifier has been applied. IIRC JSMIN and Packer do not modify the source (therefore you can always go back to the original JavaScript just by re-applying whitespace, indendation, etc), while yui-compressor and Google's do modify the source to remove dead branches, optimize, etc My proposal: 1. Have multiple versions of JavaScript libraries, very much like we have multiple versions of binary libraries with soversions, different package names (libfoo1, libfoo2, etc). We would have libjs-jquery1.4, libjs-jquery1.6, etc 2. If upstream only provides the original (non-minified) JavaScript, then we do not have a problem. This never happens, AFAIK. 3. If upstream only provides the minified JavaScript, add the package for the non-minified JavaScript as a build dependency and re-minify it. This is what I do in witty, for instance. 4. If upstream provides the original (non-minified) JavaScript *and* the minified JavaScript, ignore both of them and do same as 3 -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBoksMUmDwC2M=sq-g=v-wtqqlyfxpirtw_kcm6ybrt8q...@mail.gmail.com
Re: Dealing with embedded javascript libraries
On Sun, Oct 23, 2011 at 5:29 PM, Paul Wise wrote: > On Sun, Oct 23, 2011 at 11:13 PM, Raphael Hertzog wrote: > > > And with javascript libraries, there's no failure at build time, > > you only discover much later when something is not working... > > This is the crux of the issue and it is not specific to JavaScript > libraries, anything that is interpreted has this issue. I'm pretty > sure I've seen API breakage in libraries implemented in Python for > example. > > I agree. So far it seems I have been pretty lucky with my package witty, which depends on jquery but upstream is not really happy Debian and Ubuntu replace the jquery version they have tested with. > What are your thoughts on this topic? One of the other problems with embedded JavaScript libraries is that > often only the pre-compiled/obfuscated/minified version is > distributed, which would be a violation of DFSG item 2. > > IMHO that should not be a problem provided that: - The JavaScript library is open source with the proper license, etc - Upstream is using the Javascript library "as is" (i. e. with no local modifications) Maybe README.Debian should mention "this package embeds the JavaScript library XXX which is available independently in package libjs-XXX (source package: libjs-XXX) :-? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Bug#576718: ITP: spokify -- a KDE client for Spotify
Package: wnpp Severity: wishlist Owner: Pau Garcia i Quiles Please note Spokify 1.0 is not available yet (it will be in a couple of weeks, according to the author). I am submitting this ITP so that the ITP for libopenspotify (which Spokify depends on for now) I filed a while minutes ago is better understood. * Package name: spokify Version : 1.0 Upstream Author : Rafael Fernandez Lopez * URL : http://gitorious.org/spokify * License : GPL Programming Lang: C++ Description : a KDE client for Spotify Spokify is a KDE client for the Spotify web music store/service. It is fully integrated with KDE technologies for settings storage, password management (KWallet), notifications (KNotify), etc Spokify can use the official, closed-source libspotify or the open-source, unofficial libopenspotify libraries. A premium subscription to Spotify is required to use Spokify. -- 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/20100406181853.26563.95932.report...@mcpau
Bug#576714: ITP: libopenspotify -- an opensource libspotify-compatible implementation
Package: wnpp Severity: wishlist Owner: Pau Garcia i Quiles * Package name: libopenspotify Version : 20100217 Upstream Author : Noah Williamsson * URL : http://eternalmedia.se/openspotify/ * License : BSD Programming Lang: C Description : an opensource libspotify-compatible implementation Openspotify is an open source, cross platform re-implementation of Spotify’s closed source libspotify library. It’s aimed to replace the library used by despotify while making it easy to switch to libspotify in the future. Just as with the official libspotify library, and as stated in the FAQ at despotify.se, a premium subscription is required. -- 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/20100406175144.26088.4056.report...@mcpau
Bug#518580: ITP: osgppu -- offscreen renderer using GLSL shaders for computations
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist * Package name : osgppu Version : 0.4.0 Upstream Author : Art Tevs, Stephane Lamoliatte, Bob Kuhne, Christian Heine, Sean Carmody, Doug McCorkle, Valery Bickov * URL : http://projects.tevs.eu/osgppu/ * License : LGPL Description : offscreen renderer using GLSL shaders for computations osgPPU is a library to use with OpenSceneGraph. It provides you with a graph based specification of a computation pipeline which is based on so called PostProcessingUnits (PPUs). Each ppu does render a screen aligned quad in a frame buffer object. During the rendering a shader can be applied. The results (there could be many per one pass) are passed to the next ppu in the graph. The outcoming result of the pipeline can either be shown on the screen by using UnitOut? or used as a texture for other cool things. Download URL: http://projects.tevs.eu/osgppu/downloads/osgPPU-0.4.0.tar.gz -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505795: ITP: libmsn -- high-level C++ library for MSN Messenger
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Version: N/A; reported 2008-11-15 Severity: wishlist * Package name : libmsn Version : 4.0~beta1 Upstream Author : Mark Rowe <[EMAIL PROTECTED]>, Tiago Salem Herrmann <[EMAIL PROTECTED]> * URL : http://libmsn.sourceforge.net * License : GPL Description : high-level C++ library for MSN Messenger . The libmsn library is a C++ library for Microsoft's MSN Messenger service, licensed under the GPLv2. It provides a high-level interface that allows an application to access instant messaging features with ease. It is used by the Kopete IM application since KDE 4.2. . Download URL: http://downloads.sourceforge.net/libmsn/libmsn-4.0-beta1.tar.bz2?modtime=1226519186&big_mirror=0 -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#473096: ITP: witty -- C++ web framework and application server
Quoting Adeodato Simó <[EMAIL PROTECTED]>: * Pau Garcia i Quiles [Fri, 28 Mar 2008 11:36:59 +0100]: * Package name: witty Wt (pronounced 'witty') is a C++ library and application server for developing and deploying web applications. If the author names their software "Wt", why are you naming the package "witty" and not "wt"? Because "wt" is so short and common that "apt-cache search wt" returns and awful lot of results. Witty only returns this package's returns and is 100% official: the SourceForge page for the project is http://sourceforge.net/projects/witty and the mailing list is called witty-interest. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Bug#473096: ITP: witty -- C++ web framework and application server
Package: wnpp Severity: wishlist Owner: Pau Garcia i Quiles <[EMAIL PROTECTED]> * Package name: witty Version : 2.1.0 Upstream Author : EmWeb bvba * URL : http://webtoolkit.eu/ * License : dual licensed (GPLv2, commercial) Description : C++ web framework and application server Wt (pronounced 'witty') is a C++ library and application server for developing and deploying web applications. The API is widget-centric, and inspired by existing C++ GUI APIs (namely, by Qt). To the developer, it offers complete abstraction of any web-specific implementation details. A web application developed with Wt is written in only one compiled language (C++), from which the library generates the necessary HTML, Javascript, CGI, and AJAX code. Wt applications degrade gracefully, using plain HTML/CGI when Javascript is disabled or not available. Web applications can be compiled as a standalone executable which embeds an HTTP server or as a FastCGI module to use with any HTTP server which supports it (such as Apache, Lighttpd, IIS, etc).
