Easter this year is huge :
Happy Easter !
PS: If FTP masters could push the number of packages in NEW down, that would be even greater.
2007-04-08 08:53:44+0900
debian | Comments Off on Debian’s Easter
Enrico, you forgot your own advanced ways of wasting time (and have some fun). ;)
Here are the summaries of the candidate DPL platforms, in one sentence each:
93sam
Once we don't Select a friendly community where the packages towards a lot of software, community are most noticeable use to show their packages towards a problem good job.
aigarius
While I were elected DPL, I have to time leave Debian Developers Corner Site, map Search about it should not have not be Even if he has, the NM; process is before.
ajt
Ideally, I'd expect that we ought to make It work together in Linux and a DPL review of the community and October firmware resolutions recall vote maybe That's been some of stuff I've been a server near you United States.
hertzog
The sponsorship, principle.
sho
I believe admit volunteers to scratch our bug tracking system I do what I would like LowThresholdNmu to happen again; Admit it has rhymes with a few of it Debian; is to be really like to automatically see them.
sjr
To the web site, map Search Not Published Yet Back to the Debian Project Select a server near you United States; the web Site, map Search Not Published Yet Back to the debian For other contact information, See the Debian Project Select a server near you United States.
stratus
It is today in the web team, the users: and waited supergroups i will that any Debian support: this change our major Desktop, with Lenny development website, we've now almost our official status and how a statistics page.
svenl
To the ban.
wouter
I am of a native Dutch is not an area where possible.
These summaries have been generated by the following script:
for i in 93sam aigarius ajt hertzog sho sjr stratus svenl wouter; do
echo $i
lynx -dump -nolist http://www.debian.org/vote/2007/platforms/$i | dadadodo -c 1 - 2> /dev/null
done
It is somehow subobtimal, as aigarius and sjr's summaries show: the headers and footers of the page have some influence, but well... it was fun anyways.
2007-03-02 14:09:56+0900
debian | Comments Off on DPL platforms summaries
Marc, this is not a problem with the Debian BTS, but with BTS in general. What you describe also happens with Mozilla and Gnome BTS, speaking of those I know. The Mozilla Bugzilla is indeed an example of what NOT to try to replicate, it's probably even worse than the Debian BTS.
2007-01-06 16:40:47+0900
Or, if you really want to, be careful that, if /usr/lib/iceape/chrome is a directory (and not a symbolic link), your working directory is /usr/lib/iceape/chrome, or you will end up with the content of your current directory in /usr/share/iceape/chrome, which may be a big issue if you run apt-get from /.
If /usr/lib/iceape/chrome is a symbolic link, no worry, just ignore this message.
Thank you for your attention, and very sorry :(
Update : That's in such cases that you'd like special crafted tools to rebuild packages without the need to rebuild the whole thing when it comes to just change maintainer scripts (pre/postinst, pre/postrm...). Fortunately, I have pbuilder configured with ccache, but that doesn't help the buildds with their build job.
2007-01-04 21:49:48+0900
iceape | Comments Off on Do NOT install iceape release 1.0.7-1
I was preparing security updates for all the Mozilla® products in stable and needed some feedback from their security team...
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
security@mozilla.org
SMTP error from remote mail server after RCPT TO:<security @mozilla.org>:
host dm-mail02.mozilla.org [63.245.208.176]: 554 5.7.1 Service unavailable; Client host [xx.yy.zz.tt] blocked using dnsbl.sorbs.net=127.0.0.10;
+Dynamic IP Addresses See:
http://www.sorbs.net/lookup.shtml?xx.yy.zz.tt
Damn. And my ISP relay decided to reject my mail. Do we have a relay for DDs in need somewhere ?
Update: It seems retrying was enough, there might be a problem with one of my ISP relay servers...
2006-10-28 12:36:36+0900
or How Mozilla® Corporation is FUDing on Debian. Again.
This time, Christopher Beard, Mr Mozilla® Marketing is talking about Firefox® in Ubuntu, that it's great, Ubuntu is a good boy, that it cooperates with Mozilla®, and that by cooperating, it can use the great Firefox® name and logo.
To be honest, I don't care that Ubuntu calls Firefox® Firefox® instead of Iceweasel or whatever. I don't care that Ubuntu doesn't care about freedom as much as Debian does. I could not care less.
But, indeed, I do care about (yet other) false claims about Firefox® in Debian.
Let's see what Christopher has to say about it:
I understand that Ubuntu is based upon Debian. Is that the same or different than the IceWeasel browser that Debian is shipping with their latest release?
It's different. The patches that Debian applied to the Mozilla source code (which then resulted in their IceWeasel product) are more significant in scope than those in what Ubuntu is shipping (and branding as an official Mozilla Firefox release). Firefox in Ubuntu represents a somewhat more modest set of divergences from original Mozilla source code.
Let's check out what it is about. And as I don't want people to doubt my words, I'll give you, readers, the ability to check for yourself what it is all about.
First, please download the latest currently available patch for Firefox® 2.0 beta 2 in Debian. It has been in experimental for some weeks now. It is a bit different from the patch I described earlier, so I'll also tell you what has been changed since this 2.0b2 patch:
(Also note that another change has been done since then, which is actually reverting a previous patch on gfx/src/gtk/mozilla-decoder.cpp, that was adding code that became dead code when we changed the way to fix the bug.)
Next, please download the official and supported Firefox® diff from Ubuntu.
Uncompress both these diff files, and create two directories (let's call them ubuntudiff and debdiff) which will contain the individual patches for each file. To fill these directories, please use the following commands:
$ filterdiff --strip=1 firefox_2.0+0dfsg-0ubuntu3.diff > ubuntu.diff
$ filterdiff --strip=1 firefox_1.99+2.0b2+dfsg-1.diff > deb.diff
$ cd ubuntudiff
$ splitdiff -d -a ../ubuntu.diff
$ cd ../debdiff
$ splitdiff -d -a ../deb.diff
If you don't have the splitdiff and filterdiff utilities, you can get them from the patchutils tools (you will also need another of these tools later).
Now, let's have fun with these split patches...
Files that are only patched in Debian: (excluding any file that would be in the debian subdirectory, that contains maintainer scripts for build and installation)
$ LANG=C diff -ru debdiff/ ubuntudiff/ | grep "^Only in deb" | grep -v debian | wc -l
6
So, that's 6 files that Debian patches that Ubuntu doesn't. Let's check what they are:
$ LANG=C diff -ru debdiff/ ubuntudiff/ | grep "^Only in deb" | grep -v debian
(reordering result for convenience)
Only in debdiff/: browser_base_content_aboutDialog.xul
Adds rows=5 to the user agent textbox so as to display the user agent string uncut by default
Only in debdiff/: content_html_content_src_nsGenericHTMLElement.cpp
Only in debdiff/: content_html_content_src_nsHTMLInputElement.cpp
Only in debdiff/: dom_src_base_nsGlobalWindow.cpp
It's a patch I submitted in bugzilla #343953 and that got applied in Firefox® 2.0. No surprise the patch is not applied on Ubuntu.
Only in debdiff/: extensions_reporter_Makefile.in
Patch I submitted in bugzilla #354413 and that got applied in Firefox® 2.0.
Only in debdiff/: security_coreconf_rules.mk
Patch from bugzilla #325148 that got applied in Firefox® 2.0 (see above), and a small patch to build the NSS library with debugging symbols (put -g in CFLAGS).
That leaves only 2 small patches : CFLAGS = -g added to security/coreconf/rules.mk and rows=5 to browser/base/content/aboutDialog.xul
Files that are only patched in Ubuntu: (same exceptions as for Debian)
$ LANG=C diff -ru debdiff/ ubuntudiff/ | grep "^Only in ubuntu" | grep -v debian | wc -l
45
Yes, that's right, that's 45 files that Ubuntu patches that Debian doesn't. Most are windows sizes and similar things that upstream can't get right because they are values adapted to Windows, but that also includes some changes to the code and some other things.
Let's now check differences in files that are patched in both. It's a bit of shell black magic, but you can check by hand that it does nothing wrong :
$ LANG=C diff -ru debdiff/ ubuntudiff/ | filterdiff -p1 -x configure -x debian"*" | lsdiff --strip=1 | while read f; do diff -u debdiff/$f ubuntudiff/ | awk "! /^---|^\+\+\+|^ |^[-+]*\@\@/ { print \"$f\"; exit}"; done
That gives a list of patch files that have more differences than line numbers changes, and that do not apply to the debian directory or the configure script (which is generated from configure.in), which is what we really want to compare here. You can take this list and run interdiff between these files from the ubuntudiff and debdiff directories. I'll explain for you what these differences are:
Overall, Ubuntu applies the same set of patches as Debian, plus some more. A somewhat more modest set of divergences, huh ?!?
For what it's worth, Ubuntu, like Debian, builds its Firefox® with flat chrome and pango enabled.
What's different in the shipping Ubuntu version of Firefox than the proposed Debian version of Firefox (that didn't ultimately ship)?
Technically, changes include fixes to the User Agent string and the feed preview, a well as addressing issues of coherent branding. More significant than any specific difference in code, however, is Ubuntu's commitment to work together with Mozilla and our community on releases going forward to insure product quality and integrity.
Why are you working with Ubuntu when you wouldn't work with Debian?
We did try to work with Debian and would prefer a situation in which we work together. Ultimately, Debian took a position that was consistent with their own policies, and not compatible with some of the exceptions to Mozilla trademark policies that we offered. While we understand and respect their decision not to work with us under our branding guidelines, Mozilla believes that brands like Firefox are important for consumer protection. In any event, Ubuntu developers are working closely with Mozilla developers to insure product quality and features that are what users expect when they use Mozilla Firefox, which means that they'll ship (and will continue to ship) a fully branded version.
Reading between the lines, that means Debian is not working with Mozilla. It's not like we're submitting patches. No. Never. Ever. I'm also glad to hear from Asa Dotzler, in comments to Mr Beard's article, that this great collaboration with Ubuntu will lead to patches applied to Firefox® (I guess the paid Canonical employees having more time to deal with Mozilla® than the volunteer Debian maintainers may have helped, especially considering they didn't have to do all what we already prepared). Anyways, it's not like some of the patches we sent got applied.
So, while I'm at it, here is an exhaustive list of the bugs where we took or sent the patches that are applied to Iceweasel: #51429, #161826, #252033, #258429, #273524, #287150, #289394, #294879, #307168, #307418, #314927, #319012, #322806, #323114, #325148, #326245, #330628, #331781, #331785, #331818, #333289, #333308, #343953, #345077, #345079, #345080, #345413.
These don't cover the following patches (see the rationale for these in my previous article):
It's so great to spend a great amount of time on a package, send patches, try to understand how things work to get patches applied, and yet, see such denial and false claims about our work. So please, Christopher, Asa, and the others, just stop talking about Debian, it will be better for everyone.
PS for Rob in comments out there: No, ColorZilla won't work on Ubuntu, because of the ABI incompatibility I explained in my previous entry, that Mozilla® doesn't seem to care much about.
2006-10-26 22:48:01+0900
Interestingly, I see in my apache logs quite some hits from Iceweasel, even though we haven't uploaded an Iceweasel package yet. A few are coming from the gnuzilla Iceweasels, but some others obviously come from people changing their User-Agent string on purpose:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003 IceWeasel/2.0
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060830 Iceweasel/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-2)
(...)
2006-10-17 19:42:51+0900
There have been quite some comments on the Iceweasel case all over the planets, and I saw several assertions, especially from the Mozilla® camp, that I, as the Firefox® co-maintainer, the xulrunner maintainer, and (soon) Seamonkey™iceape co-maintainer, have to rectify.
They broke the --enable-official-branding flag
Half-true. We just replaced Bon Echo/Deer Park with Firefox® at the appropriate places in the build tree so that we could have Firefox® with the "unbranded" logo instead of the official logo, as Gervase Markham gave us authorization for. You're still free to enable the official branding, except that since the logos and stuff are non-free, we removed the other-licenses/branding/ directory from the original tarball, thus yes, the flag is half broken.
Firefox® logos being subject to trademarks, Debian thinks they are not free.
Trademark and copyright are different things. Mozilla® has unnecessarily given a non-free license to "clarify" the trademark situation, but that is not required. To make it clear: Debian thinks the logos are not free because they are not free. Period.
Debian isn’t properly collaborating with Mozilla®, sending unusable 100000-lines patches for validation just before releases (as seen on Lucas Nussbaum's blog)
Let me take the firefox_2.0~rc1+dfsg-1.diff.gz file, strip the debian directory from it (it only contains maintainer scripts, our set of icons and some debian specific searchplugins), and strip the configure diff that is generated by autoconf due to some changes in configure.in... that's exactly 2654 lines of diff. Very far from the 100000-lines patches they are claiming.
The Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions (from Lucas's blog again).
So, let's dig into our firefox_2.0~rc1+dfsg-1.diff.gz:
That's not that many changes, and most of them were taken from either some Mozilla® CVS trunk or the Mozilla® Bugzilla™. And most of those that were not taken from there have been sent, except those that really don't make much sense outside Debian. So, where are these frozen API changes ?
And we're not properly collaborating, huh ?
The Mozilla® project started by coming to a (admittedly uneasy) agreement with Debian for use of the name, but the Debian version diverged even further from the official version, so the permission was revoked. (from comments on Matthew Garrett's blog)
That one is really interesting, because between the time we got this understanding with Gervase and now, we are actually less diverging from the official version than by then. The main difference by that time was the extensions manager, which, in Debian, needed a lot of changes to actually act as it should, especially with globally installed extensions. I'm not saying the Debian one was perfect, it also had its own problems, but that was a whole lot less than the blatant crap that was the official one, obviously written for Windows without any thoughts for unix, and especially linux distributions.
The only main difference now, between the official Firefox® and ours, is that our build has the pango backend enabled, which we chose over the Xft backend for several reasons I won't explain here. The others differences are that we use system libraries where possible, instead of the bundled libpng, libjpeg, libtiff, libmyspell and libcairo. We also build a flat chrome, instead of having everything in .jar files.
Now, a little bit about differences the Mozilla® guys don't seem to care about while they really should: distributions build the Mozilla® products with gcc 4.x, while the official binaries are built with gcc 3.4, as well as the extensions distributed on addons.mozilla.org. Fortunately, not a lot of extensions make use of binary components, and not a lot are linked against the standard C++ library, but when that happens (like with colorzilla), you get a component linked against libstdc++5 to load on a Firefox® that is linked against libstdc++6. You are lucky if that setup doesn't crash.
Little extra from comments in Lucas's blog:
Is it possible for the Debian Firefox maintainers to create an installer package for contrib which will install the vanilla FireFox from Mozilla’s site.
How great would it be to have a package for one architecture instead of 12, and with a dependency on libstdc++5, that almost no other package uses any more.
Update:
Debian is going to replace Firefox® with a GNU fork called Iceweasel
Half-true. For the etch release, Iceweasel will only be Firefox® with a different branding. We are taking the Iceweasel name because it was already know as a possible alternative name for Firefox® when the trademark concerns have been raised more than 2 years ago (thanks Nathanael Nerode for this nice name, by the way). It appears that the GNU guys decided to start a fork with this name... that's quite unfortunate, actually. Anyways, the plan is to get in touch with them to see what we can do together, but with the etch release approaching, we can't and won't do more than a rename for the moment.
Update 2:
We (Mozilla®) presently have working relationships with most of the major Linux distributions, including Red Hat, Novell, and Ubuntu (As seen in several posts from people of the Mozilla® Corporation or Foundation)
Very interesting. Ubuntu uses the same set of patches as Debian, with some more of their own, and even releases beta software in their official releases. But when it's Ubuntu, it's fine. Sorry, I forgot Debian is lame, and DDs are frustrated fanatic integrists, on top of being bloody fanatic assholes.
Update 3: Added some precisions about other differences with the official binaries, and a small patch I somehow forgot.
2006-10-15 22:49:34+0900
Reading about the future of the (now) Adobe Flash Player plugin for Linux on the Penguin.SWF blog, I came to the conclusion that the plugin API for browsers (NP Runtime) just sucks.
Why on earth do a plugin need to depend on openssl, while the browser already deals with SSL and associated certificates. That also means plugins will deal very badly with client-side certificates.
I guess plugins also have to implement HTTP requests themselves...
2006-10-01 15:48:02+0900
Thanks to David Nusinow, Thierry Reding, Kristian Høgsberg and Michel Dänzer to have made this possible.
It's really nice looking, but damn, this is soooooooooooooo slooooooooooow. I already tweaked my X configuration, so that GL applications would be fluid, and they are, but compiz is so much slower than all the rest of the GL applications that I really wonder what's going on. Is it so much more difficult to display 3 windows than to display the full earth with plenty of textures ?
As a bonus, for an unknown reason, it cuts the nautilus desktop window at a width of 1024 instead of 1280., which makes the right of the screen a warp zone...
(For the record, I have a Radeon Mobility 9200 with the x.org drivers ; I should try with the proprietary ones)
Update : The slowness might be related to this message:
libGL warning: 3D driver claims to not support visual 0x4b
Update 2 : According to this comment from Michel Dänzer, the above message is only cosmetic.
I solved my slowness problem ! I just needed to switch back to XAA instead of EXA as an acceleration method (Option "AccelMethod"). There still remains the geometry problem... even fullscreened windows are limited to a width of 1024, though the gnome panel is correctly at the right-most of the screen (I use a vertical panel on the right of the screen).
There is also a cosmetic problem when switching from "normal" use to GL use (like cube rotation, window moving with wobbly, etc.): the window contents are kind of blured, but there's nothing we can do about that, except have the windows blured in the same way in the first place.
Ah, and scrolling in windows is more sluggish, now.
Update 3 : After some tracing of compiz, and some reading of the source code, it appears that the width limit problem is indeed due, as suggested by Hez in the comments, to GL_MAX_TEXTURE_SIZE being 1024 (you can display it with glxinfo -l | grep GL_MAX_TEXTURE_SIZE). I wonder if, as suggested by erich, there is really an environment variable to change that...
2006-09-30 09:04:02+0900
The contents of this site are licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Comments copyrights belong to their respective authors.