Kernel 2.4 in Etch (was: Re: Re: /run vs /var/run)

Are we seriously expecting to ship etch with 2.4 kernels? Is anyone still doing active security support for it? This point isn't too bad yet. As you've seen 2.4 had a security update a few days ago. Sure, it's from August, but 2.6 isn't doing better anyway. Some Debian kernel team people (suc

Closing bugs due to removed code (was Re: Re: c2a transition: libraries still needing transition)

BTW: there are in bts some translations of fuse's debconf templates... may I close these bugs with the upload which will remove templates at all or should I close them manually with explanation that there won't be any questions since now? As you want. See for example http://packages.qa.debi

Re: Re: removal of svenl from the project

He were slandering somebody and others were listening/reading without telling him that the behaviour is impolite? Well, then maybe it shows us all (or at least the readers) in a bad light. I'm pretty sure Sven recognized himself that he was impolite, but others certainly made him realize tha

Re: Re: removal of svenl from the project

I want to see you leave the Project if the expulsion process of both dilinger and svenl fails. Seriously, it's strange that you state that without explanation. dilinger started a process to expulse svenl. If the expulsion "suceeds", hopefully we'll be coherent and recognize dilinger for doing

No insulting messages?

But do you think that anything i said in those is insulting in some way, or a reason for me to be expelled from debian ? Referring to what came after that, I guess "jonas going on with his bullshit" is pretty close to an insult. I am also natively French-speaking, but I think you will agree

Expulsion of Andres, GR against expulsion process

When you start an expulsion process with such a poor rationale, it's pretty obvious it's going to fail. 2 small IRC logs do not constitute a rationale for starting this process. Starting an expulsion process against someone working in the same team is a strong indication that the problem isn't a

Discussing or working for Etch?

It seems that the project is splitting in two groups basically: The people that wants to work together and release Etch, and the people that with a reason or not wants to see it delayed. The minute after the release team announces that we're going to delay our next release, we will stop with these

Re: Re: removal of svenl from the project

Hi Pierre, just so that we are clear, I consider your first mail a personal insult already, especially given that your decision is based on irc logs. dilinger's proposition is certainly personal, as it targets only Sven and fortunately not the whole Project. It doesn't have to be an insult

Re: Re: Release update: minor delay; no non-RC fixes; upgrade reports

Hah...document a distribution's bugs in a wiki page is one funny idea that Knoppix used at the time I still used it, about a year ago. And it was one major reason I didn't wait to switch to Debian. It can be considered for tracking RC issues, but Roger still has a point that all bug reports may

Re: Re: Desktop task(sel) in Etch? (Bug #389092)

If you have opinions on what packages to use to complete a particular task, why are you using tasksel? If people who have opinions on what packages to use to complete a particular task shouldn't use tasksel, does this mean that people who think that GNOME should be used as a desktop shouldn't

Re: Re: Desktop task(sel) in Etch? (Bug #389092)

What I would expect at least: Rename the task from "Desktop" to "Desktop (Gnome)" so more experienced users know what's coming up. I think it could be done in 'expert' mode, but not in the normal installation mode. The next step will be that somebody else will suggest "Desktop (KDE)" liste

Re: Mass closing of bugs ?

Do you have an estimation of the proportion of bugs that should be open? If less than half of bugs not found in a version ulterior to some version should be open, closing these bugs sounds like an idea. It would be less rude to first warn about the upcoming closure and ask owners to mark these b

Re: Re: utnubu-desktop for the masses

I'm interested in a "utnubu desktop/minimal/standard" now in sid so you see my metapackage upload. With Etch, i would like to add a "utnubu desktop task" yes, but as i pointed out above it seems that we will need more than a simple task. I can help with code if -boot agree. What do you intend t

Re: BTS tag proposal "faq"

Bugs that were fixed or are to be fixed (even in unstable) shouldn't be tagged wontfix. What's the problem with simply marking the bugs as fixed in the right version? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

"Button voting" can't be implemented anyway

The web interface to the BTS is read-only. You couldn't have "button voting" anyway (and of course that would be a mess without requiring registration, which isn't implemented neither...). ---Rant--- I guess the way to go with the BTS is to switch to Bugzilla/other packaged BTS. That doesn't m

Re: Re: Which CD is a package on?

While I was going to add this to #debian's "cd contents" factoid, which used to also only mention jigdo, I noticed that someone had added an effective solution. (00:58:29) *cheal:* cd contents (00:58:29) *dpkg:* To find out what is on what cd, download the .jigdo template, and zless fooimage.j

Re: Re: How to install Suggested (Was: Are all recommended modules equally important?)

On Wed, 19 Mar 2008, Don Armstrong wrote: So you do something like: apt-get -o APT::Install-Suggests=true install foo; or similar. [Though it probably should be an easier option, it is possible to do.] Well, this hint was given now in the initial thread on Debian-Me

Re: Handling bugs properly (Was: Bug#474964: ...)

I want to hear your opinion about the following question: If you think a bug does not belong to your package, do you think it is your duty as a maintainer to reassign to bug to the package it belongs to or do you think just closing the bug is fine? Closing a report merely because it is assigned

Re: Re: Handling bugs properly (Was: Bug#474964: ...)

Closing valid bugs which were merely assigned to the wrong package isn't acceptable (though admitedly, it *is* better than just ignoring them entirely.) Closing a valid bug without fixing is generally wrong, like in this case, whether there is enough manpower to treat it or not. And if you have

Re: Re: Handling bugs properly

What is an ordinary bug submitter's recourse when a bug report is closed without resolution? The response sent to the poster is that a reasonable response must have been received (or a paraphrase); what happens then the response is missing? The exact phrasing is Their explanatio

Re: heimdal and testing

One of the things you could do is wait one day, after which cyrus-imapd-2.2 would be old enough to transition. cyrus-imapd-2.2 needs to be updated, otherwise cyrus-common-2.2 would become uninstallable due to its dependency on libkrb5-22-heimdal in testing. -- To UNSUBSCRIBE, email to [EMAIL

Re: heimdal and testing

Le April 28, 2008 06:17:10 pm Brian May, vous avez écrit : > Filipus Klutiero wrote: > > One of the things you could do is wait one day, after which > > cyrus-imapd-2.2 would be old enough to transition. cyrus-imapd-2.2 > > needs to be updated, otherwise cyrus-co

Re: being released from the hot seat

Le May 2, 2008 05:37:00 pm Andreas Barth, vous avez écrit : > Hi, > > good news for me that Marc 'HE' Brockschmidt didn't become DPL (though I > think he would've been a good DPL), so I managed to convince him to > become Release Manager. Of course, Luk stays Release Manager, and I will > also cont

Re: Re: Will nvidia-graphics-drivers ever transition to testing?

On Sat May 10 2008 12:14:22 Julien Cristau wrote: > On Sat, May 10, 2008 at 12:09:52 -0700, Mike Bird wrote: > > On Sat May 10 2008 11:03:40 Julien Cristau wrote: > > > On Sat, May 10, 2008 at 10:59:44 -0700, Mike Bird wrote: > > > > How should a package depend on a package built by module-assist

Re: Re: Will nvidia-graphics-drivers ever transition to testing?

On Sat, May 10, 2008 at 12:38:29PM -0700, Mike Bird wrote: > [Moved from debian-release to debian-devel] > > WHY ON EARTH should we intentionally require that packages install > successfully with known unmet dependencies which will cause failure > at runtime? Well nvidia-kernel should soon be

Re: Will nvidia-graphics-drivers ever transition to testing?

Le May 11, 2008 10:45:49 am Lennart Sorensen, vous avez écrit : > On Sat, May 10, 2008 at 09:08:32PM -0400, Filipus Klutiero wrote: > > The set of modules can already be updated if someone has the time and > > experience needed to update nvidia-graphics-modules-i386 and company. >

Re: Will nvidia-graphics-drivers ever transition to testing?

Le May 12, 2008 09:39:25 am Lennart Sorensen, vous avez écrit : > On Sun, May 11, 2008 at 03:39:15PM -0400, Filipus Klutiero wrote: > > Yes, the problems with conglomeration packages are the same as you'd get > > by merging 2 somewhat related source packages together, sa

Re: Re: Will nvidia-graphics-drivers ever transition to testing?

Filipus Klutiero wrote: > If nvidia prebuilt modules are merged in linux-modules-nonfree-2.6, they'll be > tied to kqemu prebuilt modules. This would hurt both nvidia LKM-s and kqemu > LKM-s, which are already in bad enough shape. you seem to have no idea how conglomeration pac

conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

Le May 13, 2008 09:39:38 am Lennart Sorensen, vous avez écrit : > On Mon, May 12, 2008 at 09:42:31PM -0400, Filipus Klutiero wrote: > > No, a more frequent change is disabling/enabling modules [on some arch]. > > Even if you were right, adding new module packages doesn't &q

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

Le May 13, 2008 09:54:46 pm Lennart Sorensen, vous avez écrit : > On Tue, May 13, 2008 at 09:27:31PM -0400, Filipus Klutiero wrote: > > Packaging icebear wouldn't necessarily be useless. I defined it as yet > > another IRC client for the sake of the example. You can imagine i

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

Le May 14, 2008 09:41:02 am Lennart Sorensen, vous avez écrit : > On Tue, May 13, 2008 at 10:32:07PM -0400, Filipus Klutiero wrote: > > I don't follow you. iceweasel, for example, is not independent from, say, > > libnspr. > > If they come from one source package, then th

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

Le May 15, 2008 09:55:40 am Lennart Sorensen, vous avez écrit : > On Wed, May 14, 2008 at 08:13:53PM -0400, Filipus Klutiero wrote: > > Your second parenthesis is wrong. Just like LKM-s when the stock kernels' > > ABINAME is bumped, applications need to be rebuilt when the A

Re: conglomeration packages (Re: Will nvidia-graphics-drivers ever transition to testing?)

Le May 16, 2008 09:10:35 am Lennart Sorensen, vous avez écrit : > On Thu, May 15, 2008 at 06:28:36PM -0400, Filipus Klutiero wrote: > > I don't see your point. > > I can have libfoo1 and libfoo2 installed and used at the same time so > both applications compiled for libfoo1

Re: divergence from upstream as a bug

I'm not sure whether you mean bug in the strict sense or in the BTS's sense. Do you think a divergence is a minor bug or a wishlist "bug"? I disagree that any divergence is a bug, but there may be a request to get rid of a divergence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subje

Use origin (Handling of removed packages)

Yes, this could be solved by having APT (probably) store the origin of the package when installing. Then, for example, if an APT front-end realizes while updating package index files that a package coming from Debian is not available anymore from Debian sources, the user could be prompted. --

Did the number of installations really increase by a half in one month?

In "The number of etch installations is rocketing" Joey Hess linked to a useful graph showing the evolution of the number of installations reporting to popcon: http://popcon.debian.org/stat/sub-i386.png Petter Reinholdtsen was wondering how long the rate of increase would keep up, and it seems

Release team structure (was Release Team Meeting results (the Juelich Edition))

Le vendredi 15 juin 2007 19:19, Andreas Barth a écrit : > Release team structure > ~~ > Steve Langasek, who served as Release Manager for the past two cycles, > doesn't want to be on the hot seat anymore. As he is still an active member > of the release team, we decided to have

Opposed (Re: Debian release versioning)

I was in favour at first sight, but not anymore. I agree with Adeodato that in general, the second integer of a software version is more meaningful that a stable update means. Also, as he wrote, it used to mean something entirely different in Debian itself, less than 4 years ago. But at least

Re: Re: feature: to add explanations of recommendations and suggestions dependencies

So there's some positive response. Where is a good place to pursue this further? Is this a debian policy change? I think there's no need for a Debian policy change to start. You should start by finding a proper way to put the recommendation and suggestion explanations in package control files.

Re: Re: RFC: DKMS - Dynamic Kernel Module Support

This is achieved through the installation of a script in: /etc/kernel/header_postinst.d/ /etc/kernel/postinst.d/ /etc/kernel/prerm.d/ A quick search with apt-file didn't return any result. Is this approach supported by Debian? /etc/kernel/header_postinst.d/ isn't supported. I remember grub u

Re: Re: RFC: DKMS - Dynamic Kernel Module Support

So, DKMS is being run after the installation of a kernel. Am I right? Yes. Btw, is all this documented anywhere? I guess it isn't. Kindly, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: RFC: DKMS - Dynamic Kernel Module Support

So, what's the final status of this thread? Should I continue working on the package? Should I drop it? I wouldn't want to drop it -- if there's no consensus or, at least, someone wanting it -- and wanting to *sponsor* it, or someone that will actually *use* it, I believe I'll put that on my pri

Re: Bug sprint !

Hi, there are currently 122 RC bugs remaining that affect both testing and unstable. We need to fix them NOW. However, in the permanent BSP state that has lasted for quite some time, people seem to lose focus on this urgent need for the release. So the idea is: 122 developers × 5 days =

debian-kernel (Re: kernel 2.6.27 in lenny?)

For kernel-related discussions, ask on debian-kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

debian-kernel (Supporting 2.6.27 in Lenny? - Long term support)

For kernel-related discussions, ask on debian-kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: debian-kernel (Supporting 2.6.27 in Lenny? - Long term support)

On ven, 2008-10-17 at 21:39 -0400, Filipus Klutiero wrote: > For kernel-related discussions, ask on debian-kernel. And for lenny-related discussions, isn't the release team concerned? :) It is, but the first team that should approve a Linux upgrade in lenny is the kernel team. Af

Re: debian-kernel (Supporting 2.6.27 in Lenny? - Long term support)

Le October 19, 2008 04:04:58 am Thomas Viehmann, vous avez écrit : > Filipus Klutiero wrote: > > It is, but the first team that should approve a Linux upgrade in lenny > > is the kernel team. After that the d-i team would be contacted. > > Could you just stop handing

Re: Include justification in tagging bugs ‘$FOO-ignore’

In other words, if a tag indicates a special case, that special case should be justified with a specific explanation. I would like to see such justification expected for every such tag, enforced by the convention that tags with *no* justification provided can be summarily removed by anyone. This

Re: Re: Include justification in tagging bugs ‘$FOO-ignore’

Filipus Klutiero <[EMAIL PROTECTED]> writes: > > In other words, if a tag indicates a special case, that special case > > should be justified with a specific explanation. > > > > I would like to see such justification expected for every such tag, > > enfor

Re: Possibility for dependencies against specific kernel modules

Hi folks Because of some recent events, I thought about the possibility for packages to depend against kernel module packages. As we don't want to dictate the usage of Debian provided kernels, we need a last resort fallback to the modules source. My first solution was something like the followi

Re: Re: Possibility for dependencies against specific kernel modules

On Sat, Nov 01, 2008 at 07:29:16PM -0400, Filipus Klutiero wrote: >> | Package: test >> | Depends: test-modules | test-source >> | >> | Package: test-modules >> | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 >> | >> | Packag

Translation debs (Re: Debconf 8 internationalization sessions report)

Le November 8, 2008 09:46:48 am Christian Perrier, vous avez écrit : > > i18n work session 2: tdebs > -- > (notes taken by Marc Hymers) > > "tdebs" or "translation debs" are an attempt to achieve two goals, by > splitting localization material out of packahes: > > - reduce

Re: Re: problems with the concept of unstable -> testing

The other way round works, too: Removing people who don't have that minimal commitment from the project and their packages from the archive would also allow us to release (a lot less) in a timely fashion. Right... And it would also help releasing timely to remove all buggy packages. --

Re: Re: problems with the concept of unstable -> testing

That works both ways - those who do contribute and help Debian across a wide range of areas should be valued and supported, even if they show that frustration from time to time. Everyone makes mistakes but why must the most active contributors be the first target of criticism when they criticise

Re: Re: problems with the concept of unstable -> testing

The single largest factor in making the atmosphere unpleasant is people who aren't contributing to Debian running their mouths on our development lists. I disagree, though I know relatively well how much people contribute. I'd rather blame the mailing lists if simple enthusiasts caused too mu

Re: Re: Sections - especially section:kde and section:gnome

On ven, 2009-01-02 at 16:55 +0100, Joerg Jaspert wrote: > I guess we actually need to consider what the sections are good for. > > Asking in a random irc channel at least didn't reveal any real > answers. > > So what about

Usefulness of sections (Re: Sections - especially section:kde and section:gnome)

Le January 7, 2009 02:32:24 am Joerg Jaspert, vous avez écrit : > > I don't remember using sections in over 4 years of Debian usage, though > > I had already used GNU/Linux for a few months before I switched to > > Debian. But I doubt even a user new to GNU/Linux would use them much. > > Everyone t

debtags facet for sections (Re: Sections - especially section:kde and section:gnome)

IMO, it would make sense to merge Debian sections into a debtags facet so that you can have multiple sections when it makes sense. The facet could still be controlled by ftpmasters if that was desired. I don't understand why you suggest creating a debtags facet replacing sections, except if you

Re: debtags facet for sections (Re: Sections - especially section:kde and section:gnome)

Le January 8, 2009 05:50:02 pm Charles Plessy, vous avez écrit : > Le Thu, Jan 08, 2009 at 03:02:23PM -0500, Filipus Klutiero a écrit : > > I don't understand why you suggest creating a debtags facet replacing > > sections, except if you plan to give exclusive control on i

Re: Re: Sections - especially section:kde and section:gnome

On Fri, 2009-01-02 at 09:34 +, Sune Vuorela wrote: > Hi! > > I have been wondering over the last months about Section: kde. > What is the correct usage of this section? .. I have tried to summarised some of the ideas of this thread in http://wiki.debian.org/DiscussionsAfterLenny/Section

Re: Re: Google Summer of Code 2009: Debian's Shortlist

> On 2009-04-11, Filipus Klutiero wrote: > > Obey Arthur Liu wrote: > >> === And the details: === > > > > [...] > > These descriptions are very short. Assuming these are the abstracts, > > that's not the students' fault. The abstracts were short

Bug#580643: [general] Chicony KU-0420 (Targus Slim Internet Media USB Keyboard) generates two incorrect symbols

Package: general Severity: minor The media player and my computer keys on the Chicony KU-0420 (aka Targus Slim Internet Media USB Keyboard) are generating wrong symbols (with XKeyboardConfig 1.8). The first generates XF86Tools instead of XF86AudioMedia and the second generates XF86Explorer inste

Re: Re: Google Summer of Code 2010 Debian Report

Obey Arthur Liu wrote: On Mon, Sep 20, 2010 at 12:47 PM, Adrian von Bidder wrote: > Hi Arthur, > > On Monday 20 September 2010 11.37:04 Obey Arthur Liu wrote: > [GSoC report] > > Hmm. It would have been nice to hear about what the students did and how > far they got in their GSoC project

Re: Google Summer of Code 2010 Debian Report

On 2010-09-23 05:32, Obey Arthur Liu wrote: On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero wrote: [...] I would recommend requiring candidate mentors to agree to share evaluations with GSoC admins, so admins can at least pick information on results when a report has to be made. Mentors

Re: Google Summer of Code 2010 Debian Report

On 2010-09-23 21:26, David Kalnischkies wrote: 2010/9/23 Filipus Klutiero: On 2010-09-23 05:32, Obey Arthur Liu wrote: On Thu, Sep 23, 2010 at 10:35 AM, Filipus Klutiero wrote: [...] I would recommend requiring candidate mentors to agree to share evaluations with GSoC admins, so admins

Re: Re: Re: Google Summer of Code 2010 Debian Report

Quoting Filipus Klutiero (chea...@gmail.com): > I must still thank you for sending a report. My first reaction was > "Finally", I am just disappointed by the content. I am disappointed by your followup and insistance. To make it clear (sorry readers, you'll need a t

Bug#612330: [general] Debian Live fails to restart

Package: general Severity: important I downloaded debian-live-6.0.0-i386-kde-desktop.img and managed to write it on a USB stick. Shutting down generally works, but restarting doesn't. After the init scripts finish, the console prints "Please remove the USB flash drive and press ENTER to continu

Bug#612359: [general] Debian Live: some Boot menu options are invisible (Memory test)

Package: general Severity: important Debian Live 6's boot menu seems to contain 14 options. I used the image debian-live-6.0.0-i386-kde-desktop.img. There are 4 Live options, 4 Text options, 4 GUI options, and 2 more, the first being Memory test. I tried the USB key on 3 PC, and I always only s

Should Debian Live be supported with lenny?

ive official The Debian Live paragraph in the release notes can be seen here: http://www.debian.org/releases/lenny/i386/release-notes/ch-whats-new.en.html#live W. Martin Borgert added the paragraph coordinating with Daniel Baumann. Daniel Baumann wrote: > Filipus Klutiero wrote: > > how/w

Re: Should Debian Live be supported with lenny?

Le February 15, 2009 06:03:46 am Daniel Baumann, vous avez écrit : > Filipus Klutiero wrote: > > Hi, > > Hi, > > first of all: you are aware that you hit the *worst* possible time of > sending that email when doing it on the *very* *evening* *when* *we* > *are* *ac

Bug#515718: [general] live: failures at shutdown on USB flash drive

Package: general Version: 5.0.0 Severity: normal When shutting down Debian Live running from a USB flash drive, one gets a bunch of errors on tty1: Cleaning up ifupdown Unmounting temporary filesystems...umount: /live/cow: device is busy umount: /live/cow: device is busy umount: /live: devic

Bug#515721: [general] live: disk1 boot method fails

Package: general Version: 5.0.0 Severity: normal Debian Live's disk1 boot method (F4, Boot from the first hard disk) fails on 2 PCs from 2 tested with Could not find kernel image: disk1 I do not have any computer with 2 HDDs, so I didn't try disk2. I got this with http://cdimage.debian.org/cdi

Re: Should Debian Live be supported with lenny?

Le February 16, 2009 05:29:21 pm Daniel Baumann, vous avez écrit : > Filipus Klutiero wrote: > > You are aware that Debian Live lenny RC1 was released on *2009-02-09*? > > no, i didn't know that *kidding* Eh, maybe I didn't know that lenny was about to be released then

Re: Requirement for a “proper manpage” for every command

Ben Finney wrote: Wording and tone aside, is that expectation reasonable? Yes. What course of action is open to a user of the package, with a maintainer who has made it plain they're not interested in following (this part of) policy? There's nothing direct you can do as user. As a packager,

Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

On Fri, 20 Mar 2009 14:45:09 +0100 (CET) Andreas Tille wrote: > I tried to find a clear advise how to reasonable format lists inside long > descriptions of packages. The only thing I know is that lines with two > leading spaces is considered verbose. Packages.gz is already 26Mb - I'd like t

Re: Re: RFC: Better formatting for long descriptions

On Fri, 20 Mar 2009, martin f krafft wrote: What we really should do, instead of clinging to the NIH-behaviour, reinventing the wheel, and polishing it over and over again is ditch the pseudo-RFC822 format we have and use Yaml instead. http://www.yaml.org/start.html htt

Re: Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

Neil Williams wrote: On Fri, 20 Mar 2009 19:15:00 -0400 Filipus Klutiero wrote: [...] > > What about a way of having a really long, detailed, nicely formatted > > description on packages.debian.org but a much shorter, more basic > > version in the Packages.gz file? >

Re: Re: grouping of alternative depends

Holger Levsen wrote: Hi, On Sonntag, 29. März 2009, Adeodato Simó wrote: > Hm? Your original mail said you wanted: > Depends: (pdns-backend-ldap + pdns-recursor) | bind9 > How does installing bind9 plus pdns-backend-ldap not satisfy the above? Sure it does satisfy the depends, but installin

Re: Re: [GSoC] KDE4/Qt4 based package manager

Christian Perrier wrote: Quoting Obey Arthur Liu (art...@milliways.fr): > > synaptic or shaman (from Chakra). I think that aptitude-gtk and adept > > are not userfriendly. Using these applications was quite difficult for > Heartfelt thank yous! (I'm the guy responsible for aptitude-gtk.. :D )

Developing aptitude frontends (was Re: [GSoC] KDE4/Qt4 based package manager)

Obey Arthur Liu wrote: Filipus Klutiero a écrit : > Christian Perrier wrote: >> Is this silly to think that, as most of the (good) work was made in >> aptitude-gtk, an aptitude-qt development would be a better idea? > At first sight, it does sound silly to me. aptitude-gtk i

Re: DEP-4: The TDeb specification.

Neil Williams wrote: Primary Motivations (in order): 1. Updates to translations should not require source NMU's. I guess that means avoiding to NMU with new diff.gz -s? If so, what are the underlying motivations? What is the purpose of creating a new binary package format for this (as o

Re: Re: DEP-4: The TDeb specification.

Neil Williams wrote: On Tue, 31 Mar 2009 13:06:35 -0400 Filipus Klutiero wrote: > Neil Williams wrote: > > Primary Motivations (in order): > >1. Updates to translations should not require source NM

Re: Re: DEP-4: The TDeb specification.

On Fri, 03 Apr 2009 04:21:59 -0400 Filipus Klutiero wrote: > That would be a nice improvement, but let me suggest another > implementation. To avoid introducing a second diff, why not updating the > regular diff (in the case of non-native packages) but indicating that >

Re: Re: Gratituous dependences among packages

What purpose is served by the existence of kde (the metapackage)? kde is the package which administrators who want to try KDE should generally install. Is there a reason why not to clarify its meaning by renaming it as 'kde-full' kde doesn't depend on the full KDE (for example, it doesn't de

Re: Re: DEP-4: The TDeb specification.

Neil Williams wrote: On Fri, 03 Apr 2009 16:45:46 -0400 Filipus Klutiero wrote: [...] <http://www.emdebian.org/media/debian-media/> > > > That would be a nice improvement, but let me suggest another > > > implementation. To avoid introducing a second diff, why not upd

tdiff (DEP-4: The TDeb specification.)

Neil Williams wrote: On Mon, 06 Apr 2009 01:13:19 -0400 Filipus Klutiero wrote: > > > > > That would be a nice improvement, but let me suggest another > > > > > implementation. To avoid introducing a second diff, why not updating the > > > > > reg

.tdeb format (DEP-4: The TDeb specification.)

> > Package management tools need a way to tell a .deb from a .tdeb - the > > two need to be handled differently by tools like dak, britney, apt, > > dpkg, reprepro, deb-gview and others. > Do you mean that package management tools need a way to tell a > traditional/current .deb from a package

Re: Re: tdiff (DEP-4: The TDeb specification.)

On Tue, 07 Apr 2009 09:57:30 -0400 Filipus Klutiero wrote: (Could you add a blank line between the quoted reply and your content? It makes the content easier for me to read. Thanks.) I'll try to. > Neil

Re: Re: .tdeb format (DEP-4: The TDeb specification.)

Neil Williams wrote: On Tue, 07 Apr 2009 10:23:37 -0400 Filipus Klutiero wrote: > > In a similar way to udebs. The .tdeb needs to be handled differently by > > package management tools (things like reprepro and dak) so that uploads > > of TDebs can be made by translation

Re: Google Summer of Code 2009: Debian's Shortlist

Obey Arthur Liu wrote: === And the details: === [...] These descriptions are very short. Assuming these are the abstracts, that's not the students' fault. The abstracts were shortened this year to 500 characters. I struggled to shorten mine to fit this. At this length, it's probably impos

KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)

Obey Arthur Liu wrote: * KDE/Qt4 Adept 3.0 Package Manager * - Student: Mateusz Marek, Mentor: *NEEDS MENTOR, see below.* Finish Adept 3.0, a fully integrated package manager for Qt4/KDE4. Adept is currently the only viable path to a Debian native package

Filed (Re: Preinstalled package manager(s) for PCs (wheezy))

This didn't generate as much feedback as I hoped, but I filed a ticket asking task-desktop to install synaptic: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667703 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...

Re: Bug#671503: general: APT repository format is not documented

Could you clarify how this differs from #481129? -- 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/4fb3d965.5030...@gmail.com

Use cases for CD installs (Re: Wheezy release: CDs are not big enough any more...)

Steve Langasek wrote: On Sun, May 13, 2012 at 10:26:13PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On Dom 13 May 2012 21:40:10 Marco d'Itri escribió: > [snip] > > Does anybody actually know that people routinely try to install desktop > > systems with only a CD and no networking,

Making mailing list discussions more viable (Re: Making -devel discussions more viable)

Hi Stefano, Russ and everyone, thanks for your interest in this topic. I entirely agree that we should do better in this area. Since the discussion problem is not specific to debian-devel, I'm moving this to debian-project. Stefano Zacchiroli wrote: On Mon, Apr 30, 2012 at 10:11:23AM -0700, R

Duplicate

reassign 481129 debian-policy merge 481129 671503 thanks On 2012-05-17 07:48, Michal Suchanek wrote: Excerpts from Filipus Klutiero's message of Wed May 16 18:44:21 +0200 2012: Could you clarify how this differs from #481129? It's 4 years later. Sorry, forgot that I filed the bug already. It'

Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy)))

On 2012-04-05 20:20, Filipus Klutiero wrote: This didn't generate as much feedback as I hoped, but I filed a ticket asking task-desktop to install synaptic: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667703 Joey Hess changed tasks to bring Synaptic in KDE, LXDE and Xfce. Only the

Apper instead of Synaptic for KDE (was Re: Mostly solved (was Re: Filed (Re: Preinstalled package manager(s) for PCs (wheezy))))

Hi Matthias, On 2012-06-27 14:54, Matthias Klumpp wrote: Hi! How odd that I didn't notice that bug... (I'm the GPK/PK maintainer) Well, I think pulling in Synaptic on KDE might be a bad idea, probably KDE desktop packages should pull in Apper instead, a KDE package manager based on PackageKit an

MySQL is still in unstable (Re: Bug#593463 closed by Debian FTP Masters (Bug#680362: Removed package(s) from unstable))

Hi Alexander, On 2012-07-05 11:58, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the mysql-server-5.1 package: #593463: [phpmyadmin] Failed ALTER query reports success It has been closed by Debian FTP Masters. Their expla

NEWS.Debian entries intended for developers - backwards-incompatible changes in Perl HTML::Tree (Fwd: apt-listchanges news for vinci)

Hi, Perl HTML::Tree 5 has backwards-incompatible interface changes. Version 5.00-1 added a NEWS.Debian entry to warn about that. As the entry below shows, it is intended for developers (although it could actually make sense to warn users too that the interface is unversioned). But it also show

  1   2   >