Re: Notice spam
On Mon, Mar 10, 2008 at 10:55:59PM +0100, Adam Borowski wrote:
> (...) If I'm running Debian, I know it well that I'm running Free
> Software and there's no warranty. Especially after having a wall of
> text pushed right in my face on login (by default), any subsequent
> notices are not only redundant but also annoying.
Well, many users use {x,k,g}dm to login and don't have this wall of
text pushed to them at login. But I partially support your point; I
get annoyed everytime xsane gives me a popup at startup time for me to
click-through the license.
> Imagine (...) Or me, having something pushed off the scrollback by
> "bc"'s junk from each invocation.
alias bs="bc -q"
--
Lionel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: ttf-linex -- Free fonts for education and institutions
Quoting Andreas Tille ([EMAIL PROTECTED]): > On Mon, 10 Mar 2008, Christian Perrier wrote: > >> This (still quite informal) group tries to gather people >> maintaining font packages in Debian (and CDDs). > > "and CDDs" is redundant, because CDDs are included in Debian. > Damn, one more point to change the name of the beast because > it is terribly missleading ... Sorry, I often misuse "CDD" to mean "derivative distributions"..:-) And by derivative distros, I do not only mean Ubuntu, of course, but for instance the various custom distros using by the vairous "Juntas" in Spain, the most well-known being LinEx, of course. signature.asc Description: Digital signature
Re: ITP: ttf-linex -- Free fonts for education and institutions
Quoting José L. Redrejo Rodríguez ([EMAIL PROTECTED]): José sent a request to join the group on Alioth which I grantyed yesterday. > I'll be glad in joining to the group if it does not mean more work ;-) Not really. It just means you check out svn+ssh://svn.debian.org/svn/pkg-fonts/packages and look there how package maintainers have organised their work place (I suggest ttf-dejavu or ttf-sil-abyssinica as example... > Also if the group wants to package these fonts, I'll even be glader to > give you the ITP. My main purpose is include these fonts in Debian as We don't really claim to maintain all font packages. The group is still quite loose wrt this. We can probably take some packages over in case they become unmaintained but we still need someone particularly motivated for this or that package to take care of it. Here's what we use in ttf-dejavu: Maintainer: Debian Fonts Task Force <[EMAIL PROTECTED]> Uploaders: Davide Viti <[EMAIL PROTECTED]>, Christian Perrier <[EMAIL PROTECTED]>, Eugeniy Meshcheryakov <[EMAIL PROTECTED]> Here, Davide is the package maintainer. I've been added to Uploaders as well as Eugen so that we can "safely" upload the package in case of emergency without it to become an NMU. This way, bug reports for the package go to the fonts devel mailing list which has proven fine as of now. (we did setup a pkg-fonts-bugs mailing list but that seems to be slightly overkill) signature.asc Description: Digital signature
Re: ITP: ttf-linex -- Free fonts for education and institutions
On Tue, 11 Mar 2008, Christian Perrier wrote: Sorry, I often misuse "CDD" to mean "derivative distributions"..:-) Yep. I'm quite bored of this (which is not your fault but common practice because of the very badly choosen name). I just registered "CDD renaming BOF" at https://penta.debconf.org/penta/submission/dc8/all_events so feel free to join because the name just disturbs the potental the idea has. IMHO it also has potential for i18n efforts! And by derivative distros, I do not only mean Ubuntu, of course, but for instance the various custom distros using by the vairous "Juntas" in Spain, the most well-known being LinEx, of course. BTW, the school part of LinEx is currently joining / merging with Debian-Edu and IMHO there would be a great potential to build a Debian-Government CDD based in LinEx work if they would decide to merge their stuff to "upstream" Debian. See you in Argentina Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: ttf-linex -- Free fonts for education and institutions
El mar, 11-03-2008 a las 07:26 +0100, Christian Perrier escribió: > Quoting José L. Redrejo Rodríguez ([EMAIL PROTECTED]): > > José sent a request to join the group on Alioth which I grantyed yesterday. > > > > I'll be glad in joining to the group if it does not mean more work ;-) > > Not really. It just means you check out > svn+ssh://svn.debian.org/svn/pkg-fonts/packages and look there how > package maintainers have organised their work place (I suggest > ttf-dejavu or ttf-sil-abyssinica as example... > ok, that seems easy ;-) > > > Also if the group wants to package these fonts, I'll even be glader to > > give you the ITP. My main purpose is include these fonts in Debian as > > > We don't really claim to maintain all font packages. The group is > still quite loose wrt this. We can probably take some packages over in > case they become unmaintained but we still need someone particularly > motivated for this or that package to take care of it. > > Here's what we use in ttf-dejavu: > > Maintainer: Debian Fonts Task Force <[EMAIL PROTECTED]> > Uploaders: Davide Viti <[EMAIL PROTECTED]>, Christian Perrier <[EMAIL > PROTECTED]>, Eugeniy Meshcheryakov <[EMAIL PROTECTED]> > > > Here, Davide is the package maintainer. I've been added to Uploaders > as well as Eugen so that we can "safely" upload the package in case of > emergency without it to become an NMU. > > This way, bug reports for the package go to the fonts devel mailing > list which has proven fine as of now. > > (we did setup a pkg-fonts-bugs mailing list but that seems to be > slightly overkill) > Ok, it sounds perfect for me, so I'll put the group as Maintainer and myself as an Uploader, just tell me if there is any policy about who else should be uploader or if any of you volunteers. Cheers. José L. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Please test ELinks from experimental
Hi, I uploaded ELinks 0.12~20080127-2 a few days ago to experimental. If you happen to use ELinks, please test this and report any bugs etc. that you may find. If you don't use ELinks, now is probably a good time to start using it :) This version of ELinks is based on an upstream 0.12 GIT snapshot and enables experimental features and has support for debugging compiled in. 0.12 is not considered stable enough that I can prepare packages based on it for unstable but it has UTF-8 support and a lot of other features and bug fixes. I will update the package in experimental as and when bug reports flow in and when fixes are made by upstream for the same. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature
Bug#470467: ITP: hyantesite -- geomatic tool to compute neighbourhood population potential
Package: wnpp Severity: wishlist Owner: Guelton <[EMAIL PROTECTED]> * Package name: hyantesite Version : 1.0 Upstream Author : serge guelton <[EMAIL PROTECTED]> * URL : http://hyantes.gforge.inria.fr * License : LGPL Programming Lang: C Description : geomatic tool to compute neighbourhood population potential Client to perform actions provided by libhyantes. hyantes aims to develop new methods for the cartographic representation of human distributions (population density, population increase, etc.) with various smoothing functions and opportunities for time-scale animations of maps. It provides a smoothing method related to multiscalar neighbourhood density estimation. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
actively notifying users of removed packages
Hi, I would like to bring up the issue of removed packages. I think it is problematic that sometimes packages get removed, with no automatic transition [a transitional package, or another package depending on a replacement package or conflicting with the old one], and no active notification to the user. My primary concern is security. I recently discovered many packages that have been removed from Debian, that I had still been using with no idea that they were removed. The worst part is, some of these packages were removed due to outstanding security bugs! For example, bitchx and dhcp-client. It's clear to me that a silent removal is problematic since the result is existing users keep that buggy version forever. An example of a package with a logical replacement is beep-media-player. I've been using this program without realizing that audacious has superceded it. I would have been nice, though not necessarily security-critical, to know about beep-media-player's removal. Some of the ones I've noticed are a single binary package removed where the source package still exists, e.g. hal-device-manager (which is somewhat superceded by gnome-device-manager). With ntp-simple, I don't know how, but I had both ntp and ntp-simple (version 1:4.2.2.p4+dfsg-2) installed, where ntp presumably was supposed to get rid of ntp-simple. Apparently a transitional package existed and was subsequently removed, so it fell through the cracks. [How to find out why a particular package no longer exists wasn't obvious either. A general search via Google or newsgroups usually doesn't yield anything useful; the way I've figured out how to do it is (1) look up the package in packages.qa.debian.org, (2) find a "removed from unstable" message, and (3) look up the associated bug report at bugs.debian.org.] Solutions?: Since in many of these situations there may be more than one replacement or no replacement, it makes sense that there's no automatic action via a dist-upgrade. One idea is to have a system where the user is notified when installed packages no longer exist in the apt repositories, with an explanation and suggested followups [e.g. install one of X,Y,Z, or just remove the package]. The default explanation could be just a link to the BTS page, so no extra required work for maintainers. How? Since users may have installed .deb files manually or removed lines from /etc/apt/sources.list, the existence of a package without an apt source isn't necessarily a problem. However, an active removal via an ftp.debian.org bug, or a source package no longer building a binary package, is more significant. I suggest in these cases that when the user runs apt-get upgrade, he is notified of removed packages (the first time this is noticed). This might be implemented in a separate tool hooked in similar to apt-listchanges, or integrated into apt-get and/or various frontends; the information might be part of Packages.gz or a separate file similar to ftp-master.debian.org/removals.txt. (I noticed that removals.txt only has a few months of data. The mechanism for this idea should allow for people who only run apt-get once every couple months.) Thoughts? What have I missed? Existing solutions or non-problem? How can we move towards implementing something like this? What other ideas are there for dealing with disappearing packages? Thanks, Karl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
Hi Karl, * Karl Chen <[EMAIL PROTECTED]> [2008-03-11 13:51]: > I would like to bring up the issue of removed packages. I think > it is problematic that sometimes packages get removed, with no > automatic transition [a transitional package, or another package > depending on a replacement package or conflicting with the old > one], and no active notification to the user. > > My primary concern is security. I recently discovered many > packages that have been removed from Debian, that I had still been > using with no idea that they were removed. The worst part is, > some of these packages were removed due to outstanding security > bugs! For example, bitchx and dhcp-client. It's clear to me that > a silent removal is problematic since the result is existing users > keep that buggy version forever. [...] If you are using testing please consider subscribing to secure-testing-annouce[0] to get informed about such package removals. [0] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-announce Kind regards Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgps9Qz09anEK.pgp Description: PGP signature
Re: actively notifying users of removed packages
Le mardi 11 mars 2008 à 05:23 -0700, Karl Chen a écrit : > Hi, > > I would like to bring up the issue of removed packages. I think > it is problematic that sometimes packages get removed, with no > automatic transition [a transitional package, or another package > depending on a replacement package or conflicting with the old > one], and no active notification to the user. > [SNIP] > > Thoughts? What have I missed? Existing solutions or non-problem? > How can we move towards implementing something like this? What > other ideas are there for dealing with disappearing packages? > FYI, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464021 I suppose that users having subscribed to packages in the PTS should now be notified of such removals (which used not to be the case, and worried us a great deal some weeks ago ;) My 2 cents, Best regards, -- Olivier BERGER <[EMAIL PROTECTED]> (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM & Management SudParis (http://www.it-sudparis.eu/), Evry
Re: actively notifying users of removed packages
On 11/03/08 at 05:23 -0700, Karl Chen wrote:
> I would like to bring up the issue of removed packages. I think
> it is problematic that sometimes packages get removed, with no
> automatic transition [a transitional package, or another package
> depending on a replacement package or conflicting with the old
> one], and no active notification to the user.
To get the list of packages that are installed, but are no longer part
of the archive, I use
apt-show-versions |grep 'No available version in archive'
If you are only interested in a few packages, you could subscribe to
them on the PTS. I recently worked on a script to notify PTS subscribers
('summary' keyword) when the package is orphaned or removed. (see
#464021)
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
Hi, Olivier Berger schrieb: > FYI, according to > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464021 I suppose that > users having subscribed to packages in the PTS should now be notified of > such removals (which used not to be the case, and worried us a great > deal some weeks ago ;) this suggests, that a user should subscribe to every package he or she is using. That sound a little impracticable to me considering the number of installed packages on an average desktop system. Especially if someone used tasksel. So I'd prefer what Nico has suggested: subscribing to »secure-testing-announce«. But then it would also be nice to have that like Karl suggested it. From the point of an user that would be the easiest way and integrate wonderfully into the update process. But then stable is what is worked for and if someone uses testing/unstable he/she should watch for herself or himself. So there remains only one question (for me): how is this dealt with on a dist-upgrade? Is ensured that every removed package results in some kind of notification? I believe that is not so (remembering the removal of ipac-ng). Kind regards, Kai -- Kai Wasserbäch (Kai Wasserbaech) E-Mail: [EMAIL PROTECTED] Jabber (debianforum.de): Drizzt URL: http://wiki.debianforum.de/Drizzt_Do%27Urden GnuPG: 0xE1DE59D2 0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2 (http://pgpkeys.pca.dfn.de/pks/lookup?search=0xE1DE59D2&fingerprint=on&hash=on&op=vindex) signature.asc Description: OpenPGP digital signature
Re: actively notifying users of removed packages
On Tue, Mar 11, 2008 at 05:23:45AM -0700, Karl Chen wrote: > Hi, > > I would like to bring up the issue of removed packages. I think > it is problematic that sometimes packages get removed, with no > automatic transition [a transitional package, or another package > depending on a replacement package or conflicting with the old > one], and no active notification to the user. It's no active notification, but aptitude lists all installed packages that aren't in any distribution included in sources.list under "Obsolete and Locally Created Packages". Verifying that this doesn't include any packages that I expect there (like locally compiled kernel module packages) is my way of checking for removed packages. -- Andreas Bombe <[EMAIL PROTECTED]>GPG key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
Karl Chen <[EMAIL PROTECTED]> writes: > Hi, > > I would like to bring up the issue of removed packages. I think > it is problematic that sometimes packages get removed, with no > automatic transition [a transitional package, or another package > depending on a replacement package or conflicting with the old > one], and no active notification to the user. aptitude show you a "Obsolete and locally created package" where are listed package that are not available anymore from debian. -- Rémi Vanicat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
Lucas Nussbaum wrote: > On 11/03/08 at 05:23 -0700, Karl Chen wrote: > To get the list of packages that are installed, but are no longer part > of the archive, I use >apt-show-versions |grep 'No available version in archive' Or use the aptitude frontend for package management which will show such packages under the header "Obsolete and Locally Created Packages". I'd suggest to file wishlist bugreports against any package management frontend (not including apt) that does not in some way mark packages that are no longer available in the archive (or rather, in the sources defined in the sources list). One problem of course would be if a user has old (as in: belonging to a previous release) CD images listed in his sources.list. In that case the packages will probably still just show as "Installed Packages" in aptitude. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
Alle 14:57, mar 11 marzo 2008, Andreas Bombe ha scritto: > It's no active notification, but aptitude lists all installed packages > that aren't in any distribution included in sources.list under "Obsolete > and Locally Created Packages". Verifying that this doesn't include any > packages that I expect there (like locally compiled kernel module > packages) is my way of checking for removed packages. aptitude should perhaps list packages that became (that is, are and weren't before) obsolete (= not being in any archive? removed?) every time actions are performed through its CLI? Seems like an efficient way... -- Luca signature.asc Description: This is a digitally signed message part.
Re: DD in Antarctic Continent?
Hi, And I filed this as Bug#470495. I wish someone fix this bug :) -- Regards, Hideki Yamane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian's use in the Human Genome Project mentioned in the The Guardian
A couple of weeks ago The Guardian ran a story about computing and DNA sequencing where I work at the Sanger Institute, and it's nice to note that they actually mention that we use Debian: http://www.guardian.co.uk/technology/2008/feb/28/research.computing Just thought you might like to read that as a break from the flame wars. :-) Regards, Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test ELinks from experimental
On Tue, Mar 11, 2008 at 03:51:14PM +0530, Y Giridhar Appaji Nag wrote: > Hi, > > I uploaded ELinks 0.12~20080127-2 a few days ago to experimental. If > you happen to use ELinks, please test this and report any bugs etc. that > you may find. If you don't use ELinks, now is probably a good time to > start using it :) May I suggest that such announcements also go to debian-user. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Bug#463029: ITP: synce-sync-engine -- Synchronization Engine for Windows Mobile devices
Cheers, Here's a poke from a user of PocketPC. Since OpenSync supports Google Calendar, I'd be really interested that it works with WM. How's it going? Also, a side-question. Is it possible to use upstream synce-sync-engine without compiling other parts of SynCE from source, that is, combined with current Debian version? Ivan Vucica -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#463029: ITP: synce-sync-engine -- Synchronization Engine for Windows Mobile devices
On Tue, Mar 11, 2008 at 06:48:00PM +0100, Ivan Vucica wrote: > Here's a poke from a user of PocketPC. Since OpenSync supports Google > Calendar, I'd be really interested that it works with WM. How's it going? SyncEngine and its OpenSync plugin only provides information to OpenSync. I haven't heard of anyone trying with Google Calendar, but if SyncEngine and Google Calendar are both working fine with OpenSync, I don't see why it wouldn't work. If you give it a go, it could be useful to post on the synce-users mailing list[0] with your experience. > Is it possible to use upstream synce-sync-engine without compiling > other parts of SynCE from source, that is, combined with current Debian > version? Simply, yes. Regards, [0] https://lists.sourceforge.net/lists/listinfo/synce-users -- Jonny Lamb, UK [EMAIL PROTECTED] http://jonnylamb.com GPG: 0x2E039402 signature.asc Description: Digital signature
Re: actively notifying users of removed packages
On Tue, Mar 11, 2008 at 03:59:13PM +0100, Frans Pop wrote:
[...]
> I'd suggest to file wishlist bugreports against any package
> management frontend (not including apt) that does not in some way
> mark packages that are no longer available in the archive (or
> rather, in the sources defined in the sources list).
[...]
On the surface, this also sounds like a good idea for a wishlist bug
(commented default config example or whatever) against cron-apt.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
On Tue, 11 Mar 2008 05:23:45 -0700, Karl Chen wrote: > Thoughts? What have I missed? Existing solutions or non-problem? Not a general solution probably but maybe interesting for you is the following RSS feed: http://ftp-master.debian.org/~joerg/removals/removals.rss Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Van Morrison signature.asc Description: Digital signature
Re: actively notifying users of removed packages
Hi, Am Dienstag, den 11.03.2008, 05:23 -0700 schrieb Karl Chen: > Thoughts? What have I missed? Existing solutions or non-problem? > How can we move towards implementing something like this? What > other ideas are there for dealing with disappearing packages? A solution that’s possible without big changes would be a package "removal-notifier" which contains a manual list of removed packages (which needs to be maintained by someone of course) and can tell the user about packages he has installed but that are on that list. Not very elegant, but it would work and probably quite easy to implement. Just a quick idea, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
dpkg with triggers support (again)
Anthony Towns writes:
> Beyond that, any additional uploads of dpkg will be REJECTed
Therefore dpkg 1.15.2 is now available here, as sources and i386
binaries - a complete upload ready to go into sid:
http://www.chiark.greenend.org.uk/~ian/dpkg/
Thanks to the miracle of using git properly, I am able to get on with
real work like sorting out the build regressions which I inherited
from Raphael/Guillem's tree[1]. Thanks are due to Robert Luberda for his
helpful translation fixes, which which he committed to
Raphael/Guillem's tree and which correct one of the FTBFS bugs.
Meanwhile I see that Guillem is hard at work making future merges more
difficult.
He is polishing revision logs by rebasing changes, reorganising
commits into a different order, moving code between files,
gratuitously reformatting[2], etc.
Ian.
[1] I don't mean to imply any criticism here. Anyone can have a build
regression in their stable vcs tip for a bit.
[2] His most recent commit is 402 diff lines of stuff like this:
-static void usage(void) {
+void
+usage(void)
+{
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
Joachim Breitner wrote: > > A solution that’s possible without big changes would be a package > "removal-notifier" which contains a manual list of removed packages > (which needs to be maintained by someone of course) and can tell the > user about packages he has installed but that are on that list. > > Not very elegant, but it would work and probably quite easy to > implement. I wrote a similar script a few days ago and blogged about it[1]. Besides the comments I received I still use it because of several reasons such as: I don't use aptitude, I have some packages which I'd like to be ignored, I don't like aptitude's output, and I don't have apt-show-versions installed :). [1]http://my.opera.com/atomo64/blog/2008/03/09/where-to-put-such-a-script > > Just a quick idea, > Joachim > Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lzma: New upstream version available (#460501)
tags 460501 + help thanks Hi, Actually, I have already prepared a package for the new upstream release (4.57)[0]. The package is almost ready, it's just that I don't know how to update lzmp patch[1], I would need some help for that... Regards, Arnaud Fontaine [0] http://git.debian.org/?p=collab-maint/lzma.git;a=summary [1] debian/patches/02_lzmp.diff pgpIHbkaAGxzo.pgp Description: PGP signature
Re: dpkg with triggers support (again)
On Tuesday 11 March 2008 4:41:57 pm Ian Jackson wrote:
> Meanwhile I see that Guillem is hard at work making future merges more
> difficult.
>
> He is polishing revision logs by rebasing changes, reorganising
> commits into a different order, moving code between files,
> gratuitously reformatting[2], etc.
What is it that people don't get from git-rebase(1)?
When you rebase a branch, you are changing its history in a way that
will cause problems for anyone who already has a copy of the branch in
their repository and tries to pull updates from you. You should
understand the implications of using git rebase on a repository that
you share.
In short, never rebase something that is already public.
> [2] His most recent commit is 402 diff lines of stuff like this:
> -static void usage(void) {
> +void
> +usage(void)
> +{
Ugh. I laughed when I first read this, but now I feel more revulsion.
Ugh.
-- John
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470574: installs into non-policy-compliant /usr/libexec
Package: mingw32 Version: 4.2.1.dfsg-1 Severity: serious Justification: policy 8.2 (?) Hi, After installing mingw32, I noticed the following files in /usr/libexec/gcc, they should be installed to /usr/lib/gcc instead: /usr/libexec /usr/libexec/gcc /usr/libexec/gcc/i586-mingw32msvc /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools/mkheaders /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools/fixincl /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools/fixinc.sh /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/cc1 /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/cc1plus /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/collect2 At least in my opinion; if I am wrong then please let me know and close the bug. William -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mingw32 depends on: ii libc6 2.7-6 GNU C Library: Shared libraries ii mingw32-binutils 2.18.50-20080109-1 Minimalist GNU win32 (cross) binut ii mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runti mingw32 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: actively notifying users of removed packages
> On 2008-03-11 06:52 PDT, Lucas Nussbaum writes:
Lucas> If you are only interested in a few packages, you could
Lucas> subscribe to them on the PTS. I recently worked on a
Lucas> script to notify PTS subscribers ('summary' keyword)
Lucas> when the package is orphaned or removed. (see
Lucas> #464021)
> On 2008-03-11 06:57 PDT, Andreas Bombe writes:
Andreas> It's no active notification, but aptitude lists all
Andreas> installed packages that aren't in any distribution
Andreas> included in sources.list under "Obsolete and Locally
Andreas> Created Packages". Verifying that this doesn't
Andreas> include any packages that I expect there (like
Andreas> locally compiled kernel module packages) is my way of
Andreas> checking for removed packages.
Good points, I also discovered Synaptic works well for manually
looking for removed packages. Notifying PTS subscribers by email
also sounds very useful. Still, I worry about the people who
don't know to check for removed packages - and aren't watching
the packages that happened to be removed.
Karl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intend to hijack xchat-xsys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi debian-devel, I've been talking with the maintainer[1] of xchat-xsys[2] for several bugs and many new upstream releases hold back on Debian, and he communicated me that he is not longer interested on maintaining it any more. Unfortunately, my suggestion of orphaning the pkg made no difference to the current maintainer, as he showed no cares at all for it. With a modest popcon of 242[3] and a bug related to a dep, rendering the pkg in an unusable state, this package needs attention. If there are no objections, I plan to upload a new pkg which, not only solves the critical bug I mentioned, it incorporates about 2 years and a half of updates, solving two bugs more listened on BTS. Greetings, UlisesVitulli. ps: If It's *really* needed, there's a DD that can confirm this, but I would prefer not to involve him, as for the friendship he has with the current maintainer. ps2: thanks Andreas Henriksson at #debian-mentors 1. http://qa.debian.org/[EMAIL PROTECTED] 2. http://packages.debian.org/xchat-xsys 3. http://qa.debian.org/popcon.php?package=xchat-xsys -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH1yF0GcNpEq4d/XQRAmQIAKCPylyOA8pXku769mWnS/zhskSNuACfWGIJ vdzjf/iipHbqwLtIoDurE9Y= =WfcX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg with triggers support (again)
On Tue, 11 Mar 2008, John Goerzen wrote:
> On Tuesday 11 March 2008 4:41:57 pm Ian Jackson wrote:
> > He is polishing revision logs by rebasing changes, reorganising
> > commits into a different order, moving code between files,
> > gratuitously reformatting[2], etc.
>
> What is it that people don't get from git-rebase(1)?
>
>When you rebase a branch, you are changing its history in a way that
>will cause problems for anyone who already has a copy of the branch in
>their repository and tries to pull updates from you. You should
>understand the implications of using git rebase on a repository that
>you share.
>
> In short, never rebase something that is already public.
Rebasing *published* commits in the *mainline/master* branch is utterly
stupid.
Note that I do think you should clean up the hell out of the history and
commit logs right before a merge, use topic branches, and rebase the fuckers
right before merges to ease everyone else's lives when looking at the
history and doing bissect hunts. I have made this clear to anyone reading
my posts.
But even I agree that one MUST NEVER rebase published commits in the main
branch. There is no excuse to mess with the mainline history other than to
defang some commit that is SO dangerous, it can't be risked someone would
hit it on a bissect. I have *never* heard of something like this happening.
Now, there comes the IMPORTANT question: was the rebase done on the main
branch? Or was it a clean up operation on some topic branch before merging
it? I'd appreciate quite a LOT if such extremely important information is
also disclosed.
> > [2] His most recent commit is 402 diff lines of stuff like this:
> > -static void usage(void) {
> > +void
> > +usage(void)
> > +{
>
> Ugh. I laughed when I first read this, but now I feel more revulsion.
>
> Ugh.
Double ugh with an argh on top. It is icky (I *hate* that way of writing C
source). And to really rub it in, it makes something that was static,
non-static (i.e. it DOES change code in important ways).
You NEVER mix pure fluff changes with real changes in the same commit, it is
Bad Taste with a capital B. It is right there in the list of "DON'Ts", in
the same slot for "moving AND changing large chunks of code in one single
commit, instead of moving it unmodified in the first commit, and changing it
in a second commit".
Not to mention that this is a bad time to go fixing fluff in dpkg when there
is such a lot of outstanding code to be merged...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
contacting Mark J. Kilgard?
Hi all, I would like to resolve #467123 (non-free code in chromium), to do so I need Mark J. Kilgard to relicense some of his code (TexFont.cpp and TexFont.h). Does anyone know how to contact him? The alternative is to rewrite the code or find another implementation. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, I'd like to clarify few more things, which have been brough up the past few days. Even if I don't usually accept open invitations to flamefests (re the OP). On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote: > On Sun, Mar 09, 2008 at 10:38:44PM -0500, Steve Greenland wrote: > > On 09-Mar-08, 19:30 (CDT), Daniel Stone <[EMAIL PROTECTED]> wrote: > > > I was going to ask on which grounds exactly you were judging the dpkg > > > team's competence (and that of iwj's: have you reviewed the branch > > > yourself? can you confidently say that it's all fine?), > > The problem is not the dpkg team has reviewed the patch and had problems > > with it, it's that they've ignored it for 6 months. > > That's not the full picture. This was a nice summary. > > I don't approve of IanJ's hijack attempt, but in this he's got a > > legitimate complaint. > > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying > his triggers patch dependent on: > > - reversion to two space indenting - reversion of unrelated commits > - a policy of bulk conversion of intentation style, instead of > the current policy of gradual conversion from two-space to > four-space > > - having explicit casts to (char*) of NULL in order to support > some non-Debian architectures - having the commits not split into logical parts - having unrelated features/changes in the same branch > - having the git log not be bisectable or particularly meaningful > except historically > - having Ian be part of the dpkg team The missing changelog entries are actually minor compared to the rest of the problems with the branch. The branch has never been in an acceptable state, it needs cleanup, which Ian has refused to do, repeatedly, and wasted probably more time and everyone's energy starting this (and previous) massive flamefests than what would have taken to just fix it. About rebasing (-i), we've asked for the branch to be rebased as part of the needed cleanup (or any other method which would have resulted in a clean branch or series of patches). He could have kept his existing branch if he so desired, but I don't really see much point in that given that the resulting cleaned up branch would not resemble the original one anyway. One of his excuses was that he had based other feature branches on this one, which is another bad idea, as this was tying unrelated changes together. Also I don't think we'd have insisted on rebasing (even if I personally would prefer so) if the branch would not have been a mess, FWIW, we've merged clean branches before in the team. And I don't really understand this aversion to rebasing a branch that should be pulled from at some point (I'm obviously not talking about the official branches here), most people would find sending messed up patches unacceptable, but not this? > If he hadn't done that, afaict the patch would've been handled pretty > much the way Tollef's was. I've to say, overall, interactions with Ian have been mostly unpleasant, demotivating and confrontational. Not really my definition of "fun". > I don't believe anyone on the dpkg team at any point gave Ian a definite > answer on any of the above issues over the past months; though I doubt > he would have accepted a "no" on any of them anyway. Maybe we've not sent a strong enough message, but there was repeated long conversations, AFAIR, on mail and IRC about how we'd like to see such a branch or series of patches being submitted. Anyway, after the freeze was announced it was clear that Ian was not going to fix the branch, and because having this feature for lenny is highly desirable I was just going to have to fix it myself and review during that process, but got quite sick for a week, during which he started all this mess. I'm back on the clean/split/merge process, and should finish soonish if I don't get distracted by more useless flamefests... Also given that he does not have commit access any longer I'll be taking care of integrating any reasonable change that might be on any of his branches, in the same way we'll be getting eventually at all the remaining patches that are waiting on the BTS. And I'm also quite disappointed with the amount of people that have jumped to conclusions without knowing the context of all this. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi Guillem,
Ian wrote that you recently committed 402 diff lines of stuff
like this:
-static void usage(void) {
+void
+usage(void)
+{
It's easy to see negatives such as making it harder to merge
long-awaited features. What positives do you see for Debian?
--Mike Bird
Re: actively notifying users of removed packages
On Tue, Mar 11, 2008 at 04:19:42PM +0100, Luca Brivio <[EMAIL PROTECTED]> was heard to say: > Alle 14:57, mar 11 marzo 2008, Andreas Bombe ha scritto: > > It's no active notification, but aptitude lists all installed packages > > that aren't in any distribution included in sources.list under "Obsolete > > and Locally Created Packages". Verifying that this doesn't include any > > packages that I expect there (like locally compiled kernel module > > packages) is my way of checking for removed packages. > > aptitude should perhaps list packages that became (that is, are and weren't > before) obsolete (= not being in any archive? removed?) every time actions > are performed through its CLI? Seems like an efficient way... I wrote a patch to do this on the way to work this morning, and I think it should actually work now. Note, though, that it only works for obsolete packages in the new index: if you remove a source and update, packages made obsolete by that change aren't detected. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi,
On Tue, 2008-03-11 at 22:06 -0700, Mike Bird wrote:
> Hi Guillem,
>
> Ian wrote that you recently committed 402 diff lines of stuff
> like this:
> -static void usage(void) {
> +void
> +usage(void)
> +{
>
> It's easy to see negatives such as making it harder to merge
> long-awaited features. What positives do you see for Debian?
The horse is dead. Stop beating it.
William
signature.asc
Description: This is a digitally signed message part
, Alerta tributário: aos profissionais liberais e autônomos
Alerta tributário: aos profissionais liberais e autônomos NUNCA "COMPRE" NOTA FISCAL Evite sempre este expediente, quando for necessário apresentar Nota Fiscal para receber sua remuneração por seviços prestados. Em primeiro lugar, isto é ilegal e deixa voce irregular junto ao fisco. Além disto, isto é um mau negócio para voce, por dois motivos: · É mais caro! O custo de uma Nota Fiscal "adquirida" além dos impostos incidentes inclue uma remuneração para o emitente. · Por mais legítimos que sejam seus ganhos, voce não terá comprovação legal para origem dos mesmos. Por isto a sua utilização, como a compra de imóvel, carro, etc. fica a descoberto, por não existir origem para estes recursos. Esta situação também prejudica, suas referências bancárias, de crédito, etc. além de sua exposição ao cruzamento de informações pelo fisco. Fazer tudo de forma regular é mais simples e menos oneroso do que voce imagina. E voce resolve a questão, em todos seus aspectos. Mais informações podem ser obtidas com Ricardo Ceva e Maria Lambiasi da RC Com, no 011-3299-5975 ou através do São Paulo Office Services no DDG 0800-11-1239.
