Re: 25+2 packages with (Glade) generated C source files without the source

[Josselin Mouette]

Le dimanche 31 août 2008 à 04:17 +0300, Sami Liedes a écrit :
> I went through some of these and checked them by hand, and generally
> couldn't find the glade project anywhere in the source tarball (it
> might be in the diff, I didn't check for that - would that BTW be OK,
> to have source code in diff only?). The only questionable case I found
> by this sampling is dia, where the file is "generated by Glade and
> then hand-coded to make GNOME optional and add the underline for
> accelerated buttons".

I’m pretty sure many of the list are in similar cases. Now loading the
UI directly into the application is the standard, but not so long ago
people generated template code with glade and then edited it by hand.
The .glade file was removed simply because it has become irrelevant.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: transfering files between *.debian.org hosts

[Martin Zobel-Helas]

Hi, 

On Sat Aug 30, 2008 at 18:17:27 -0700, Russ Allbery wrote:
> A bigger problem at the kernel level is that the kernel APIs change
> constantly and have not infrequently had various GPL-only tags added that
> force OpenAFS into annoying workarounds (it is released under the IBM
> Public License, another DFSG-free license that isn't quite
> GPL-compatible).  However, for systems that run stable, the corresponding
> stable release of OpenAFS should continue to work fine.  This mostly is a
> problem if one runs a backported kernel, in which case you'll need a
> backported OpenAFS as well.
> 
> I'd certainly be happy to answer questions and help with AFS setup as I
> have time.  I'd love to have a Debian OpenAFS cell.

Most Debian Machines run no stable kernels, thus we would run into that
problem. Also many machines running with static kernels. Would that be a
problem for OpenAFS?

-- 
 Martin Zobel-Helas <[EMAIL PROTECTED]>  |  Debian Release Team Member
 Debian & GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#497236: ITP: libcpuset -- assigns a set of CPUs and Memory Nodes to a set of tasks

[Aníbal Monsalve Salazar]

Package: wnpp
Severity: wishlist
Owner: Anibal Monsalve Salazar <[EMAIL PROTECTED]>

* Package name: libcpuset
  Version : 1.0
  Upstream Author : Paul Jackson <[EMAIL PROTECTED]>
* URL : http://oss.sgi.com/projects/cpusets/
* License : LGPL
  Programming Lang: C
  Description : assigns a set of CPUs and Memory Nodes to a set of tasks

 The Cpuset System is a processor and memory placement mechanism that
 enables a system administrator to confine tasks to running on
 certain CPUs, and to allocating memory on certain Memory Nodes.
 The libcpuset library provides a convenient 'C' API to cpusets.


signature.asc
Description: Digital signature

Bug#497235: ITP:

[Aníbal Monsalve Salazar]

Package: wnpp
Severity: wishlist
Owner: Anibal Monsalve Salazar <[EMAIL PROTECTED]>

* Package name: libbitmask
  Version : 2.0
  Upstream Author : Paul Jackson <[EMAIL PROTECTED]>
* URL : http://oss.sgi.com/projects/cpusets/
* License : LGPL
  Programming Lang: C
  Description : supports multi-word bitmask operations

 This Bitmask library supports multi-word bitmask operations for
 applications programmed in 'C'. It works in conjunction with recent
 Linux kernel support for processor and memory placement on
 multiprocessor SMP and NUMA systems. The cpuset library, being
 developed in parallel, depends on this bitmask library.
 .
 Bitmasks provide multi-word bit masks and operations thereon to do
 such things as set and clear bits, intersect and union masks,
 query bits, and display and parse masks.
 .
 The initial intended use for these bitmasks is to represent sets of
 CPUs and Memory Nodes, when configuring large SMP and NUMA systems.
 However there is little in the semantics of bitmasks that is
 specific to this particular use, and bitmasks should be usable for
 other purposes that had similar design requirements.
 .
 These bitmasks share the same underlying layout as the bitmasks
 used by the Linux kernel to represent sets of CPUs and Memory
 Nodes. Unlike the kernel bitmasks, these bitmasks use dynamically
 allocated memory and are manipulated via a pointer. This enables a
 program to work correctly on systems with various numbers of CPUs
 and Nodes, without recompilation.
 .
 There is a related cpuset library which uses the bitmask type
 provided here to represent sets of CPUs and Memory Nodes. The
 internal representation (as an array of unsigned longs, in little
 endian order) is directly compatible with the sched_setaffinity(2)
 and sched_getaffinity(2) system calls (added in Linux 2.6).


signature.asc
Description: Digital signature

Re: Glade no longer generates C source code

[Neil Williams]

On Sun, 2008-08-31 at 04:17 +0300, Sami Liedes wrote:
> I grepped the source tarballs in Lenny (testing) main section for the
> note "DO NOT EDIT THIS FILE - it is generated by Glade." which
> indicates the file is generated using the Glade UI editor. Then I
> checked if these packages have any *.glade* files, which would be the
> Glade projects, i.e. the "source code" (at least in the GPL sense,
> "preferred form of modification") for these. For those of these
> packages for which this is not a false alarm, I believe this would
> fail DFSG #2, and for those being licensed under GPL, it would
> probably make them non-distributable.

No. It would just mean that Glade was used to *originally* create the
file but then the file *has* been modified (many, many times) but the
warning simply hasn't been removed.

Glade no longer even generates the C files. Glade-2 did, Glade-3 does
not. (Try it, load glade-3, create a .glade file and try to get the
interface.c, support.c and callbacks.c source code files.)

Therefore, no matter what the C files say, it is no longer possible to
generate the C files using the current version of Glade and the C files
MUST be the preferred form for modification!

I'm sorry, but it appears that you have misunderstood Glade.

> I haven't filed bugs for any of these, save for tangogps which was the
> first case I encountered and after which I got the idea to do this.

I do not think that any bugs are appropriate here. The behaviour you
seek to utilise has been removed from the program that you assert as the
generator of the preferred form.

> gpe-contacts
> support.c
> support.h

Absolute false positive - the C files have been heavily modified by
hand.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: 25+2 packages with (Glade) generated C source files without the source

[Neil Williams]

On Sat, 2008-08-30 at 23:19 -0300, Margarita Manterola wrote:
> On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes <[EMAIL PROTECTED]> wrote:
> > The only questionable case I found
> > by this sampling is dia, where the file is "generated by Glade and
> > then hand-coded to make GNOME optional and add the underline for
> > accelerated buttons".
> 
> And what's there to question, then?
> 
> This is exactly the case I was talking about.  Some people might use
> glade to generate a .c as a starting point, and then continue editing
> the file (or not, but just keep the .c file, once it's been
> generated).  This is perfectly fine, and we do NOT need the .glade
> files used.

(Especially when glade-3 does not actually support generating any C code
or updating the C source code files output by glade-2.)

Any bugs filed so far should be closed forthwith. The comment is old, it
relates to a function of Glade that was removed by Glade upstream and
whether the .glade file is distributed or not, the C can no longer be
generated with the current version of glade.

All this process has really shown is that upstream teams are commonly
lazy about removing old comments. Yawn.

Sorry, Sami, but this was a waste of effort.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: Bug#496938: ITP: libcrypt-generatepassword-perl -- perl module to generate secure random passwords

[Alexander GQ Gerasiov]

On Fri, 29 Aug 2008 08:09:20 -0300, David Bremner <[EMAIL PROTECTED]> wrote:
> 
> At Thu, 28 Aug 2008 20:27:44 +0400,
> Alexander Gerasiov wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Alexander Gerasiov <[EMAIL PROTECTED]>
>>
>> * Package name: libcrypt-generatepassword-perl
>>   Version : 0.03
>>
>>  I don't really know is this module is usefull for anybody else, but
>>  it is needed by netams ITP #496636.
> 
> Hi Alexander;
> 
> I'm sure you would be welcome to maintain this as part of the Debian
> perl module packaging team. http://pkg-perl.alioth.debian.org/
> Then sponsors come looking for you...

Nice, thanks for advice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#497236: ITP: libcpuset -- assigns a set of CPUs and Memory Nodes to a set of tasks

[Bastian Blank]

On Sun, Aug 31, 2008 at 05:31:32PM +1000, Aníbal Monsalve Salazar wrote:
>   Description : assigns a set of CPUs and Memory Nodes to a set of tasks

Does it work with the cgroup subsystem? As the documentation is 2 years
old, I doubt that.

Bastian

-- 
Wait!  You have not been prepared!
-- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 25+2 packages with (Glade) generated C source files without the source

[Sami Liedes]

On Sun, Aug 31, 2008 at 09:12:34AM +0200, Josselin Mouette wrote:
> I’m pretty sure many of the list are in similar cases. Now loading the
> UI directly into the application is the standard, but not so long ago
> people generated template code with glade and then edited it by hand.
> The .glade file was removed simply because it has become irrelevant.

Ok, my bad then. I admit I'm not too familiar with glade, although I
did know that the newest glade does not generate source code (but what
argument is that, this code was obviously generated with glade, the
existence of the newer version wouldn't magically make this the
preferred form of modification, would it!?).

Although I do wonder, since this seems to mean that the interfaces are
(or at least seem to me) quite immutable. For example, take a look at

   http://www.hut.fi/~sliedes/interface.c

which is from the package lopster.

It has a number of functions like create_window() and
create_options_win() which still at least look quite repulsive for any
attempts to make any real or substantive edits to the interface.

For example, the variable declarations in those functions:
create_window() has 541 local variables named like pixmap57, hbox419,
label547, hseparator49, frame 384. create_options_win() has 496. The
code (4710 lines in case of create_window()) doesn't look much more
editable either.

But I do trust you when you say that the "do not edit" note is
obsolete, I just wonder since after a cursory inspection this code
definitely doesn't look like anything I would want to touch to edit a
complex UI :) Of course if they are edited anyway, that might make
them the preferred form of modification.

Thanks for clarifying that, anyway, and sorry for the noise.

Sami


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 25+2 packages with (Glade) generated C source files without the source

[Neil Williams]

On Sun, 2008-08-31 at 15:08 +0300, Sami Liedes wrote:
> On Sun, Aug 31, 2008 at 09:12:34AM +0200, Josselin Mouette wrote:
> > I’m pretty sure many of the list are in similar cases. Now loading the
> > UI directly into the application is the standard, but not so long ago
> > people generated template code with glade and then edited it by hand.
> > The .glade file was removed simply because it has become irrelevant.
> 
> Ok, my bad then. I admit I'm not too familiar with glade, although I
> did know that the newest glade does not generate source code (but what
> argument is that, this code was obviously generated with glade, the
> existence of the newer version wouldn't magically make this the
> preferred form of modification, would it!?).

Of course it does! Once the functionality is dropped, there is no way to
continue working on the project without editing the C files. Developers
cannot continue using the old version of glade (it doesn't support some
of the stuff that you can do with glade).

You are confusing the two elements of Glade (v2) and the main
functionality retained in Glade v3.

Glade is about creating an interface (as an XML file, not C). Glade v2
allowed that interface to be easily converted into C code but could not
cope with any manual alterations to the C code - once you started
editing support.c, interface.c, callbacks.c etc., you were on your own.
(Trust me, it was nearly always better if you did edit the C files too.)
If you tried to re-generate, you lost all your own changes. Not good.

Gladev3 takes a more sensible approach - you create whatever C files you
need (no longer confined to particular file names) and load the Glade
XML file with a library call. Or, if you want an interface in C or you
don't want to depend on libglade, use Glade to get an idea of what kind
of interface might work and then code that in C yourself.

I didn't like this at first - it seemed to add more burden to the C
programming - but I view it differently now. The generated code is quite
awful to review later and makes project management a lot harder in the
long term. Short term convenience causing long term logjam.

> Although I do wonder, since this seems to mean that the interfaces are
> (or at least seem to me) quite immutable.

Sorry, that is just tosh. If you want to load the glade file via Glade,
you keep the XML, depend on libglade and call libglade at runtime. If
you designed the interface in Gladev2, you have the option to use the
existing C files to continue improving the interface and you don't have
to package the Glade file or depend on libglade.

Yes, it might look like more work than editing stuff in the GUI or in
the XML but in the long term it is the only sane option. To the point
that I've virtually stopped working on any other projects that tried to
generate C code, after working through the Glade migration.

There are downsides to generating C code - bloat for one.

> It has a number of functions like create_window() and
> create_options_win() which still at least look quite repulsive for any
> attempts to make any real or substantive edits to the interface.

WTF? It's actually fairly good code in most cases. One of the ideas
behind generating code is that you gain from the experience of others
and avoid common pitfalls. The limitation is that the generated C code
is too generalised which can be wasteful.

> For example, the variable declarations in those functions:
> create_window() has 541 local variables named like pixmap57, hbox419,
> label547, hseparator49, frame 384. create_options_win() has 496. The
> code (4710 lines in case of create_window()) doesn't look much more
> editable either.

That is the choice of the developers - if the developer is lazy and
designs in glade rather quickly, the number suffixes remain but glade
does/did allow developers to choose more sensible names, if the
developer takes the time to edit the properties of the widget.

> But I do trust you when you say that the "do not edit" note is
> obsolete, I just wonder since after a cursory inspection this code
> definitely doesn't look like anything I would want to touch to edit a
> complex UI :) Of course if they are edited anyway, that might make
> them the preferred form of modification.

That is something for upstream to review and, from personal experience,
I can say that, at some point, upstream will be *forced* to review all
that code and redesign it - when we get Gtk3 if not before.

Projects where the original Glade design was lazy or rushed will find it
hard to port the old generated C code but that is their choice and their
problem. Like it or not, those rushed C files are the only modifiable
form of the source code that are available for usage. Either edit those
files or remove them and replace the entire interface with one entirely
done in glade and then depend on libglade with no generated C code.

It is also possible for projects using libglade to still define some
widgets or windows in various C fi

Re: Unsafe storage device unmounting

[Cesare Leonardi]

Cesare Leonardi wrote:

In May i've sent the following mail to debian-gtk-gnome to signal this
problem but since nothing happened so far, i file a bug:

-
Since some days i've noted (updated Debian Sid) that when i right-click
on a usb stick icon and select "Unmount volume", the icon disappear
immediately but the unmount progress window doesn't appear and the
device is still mounted for some seconds.
So the problem exposed in bug #367836 is reappeared and to be sure to
not corrupt anything i have to poll the device in a terminal window
using mount to wait it to disappear.

Is the window that shows the unmounting progress lost somewhere?
-


Any news on this bug? Don't you think that it should be resolved in time 
for Lenny?
Many times i've observed that the cache sync to the usb pen drive 
happens *after* the disk icon has disappeared from Gnome desktop, in 
particular with FAT32 filesystem (seems that cache flush are much more 
fast on FAT16).


For safety now i use to:
- unmount the disk right-clicking on it;
- go to the terminal and issue a "mount" command to watch the situation: 
most of the time (99%) the disk is yet mounted;

- issue a "sync" command (with FAT32 can take some second);
- re-issue "mount": most of the time the drive in not mounted anymore;
- unplug the pen drive.

Since the problem was solved with Etch using a patch from Ubuntu, i 
suppose that such patch doesn't apply anymore.
But, to me, this bug deserve some attention, since it could cause data 
loss (and probably who will suffer of it will tend to think of a kernel 
bug rather than a gnome bug).


Regards.

Cesare.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unsafe storage device unmounting

[Neil Williams]

On Sun, 2008-08-31 at 13:51 +0200, Cesare Leonardi wrote:
> Cesare Leonardi wrote:
> > In May i've sent the following mail to debian-gtk-gnome to signal this
> > problem but since nothing happened so far, i file a bug:
> > 
> > -
> > Since some days i've noted (updated Debian Sid) that when i right-click
> > on a usb stick icon and select "Unmount volume", the icon disappear
> > immediately but the unmount progress window doesn't appear and the
> > device is still mounted for some seconds.

Have you disabled dbus notifications? The point at which the icon
disappears is not the point at which the drive is safe to remove. DBus
normally raises a notification window "Data is being written to the
device" followed by "Device is now safe to remove".

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: 25+2 packages with (Glade) generated C source files without the source

[Neil Williams]

On Sun, 2008-08-31 at 15:27 +0200, Josselin Mouette wrote:
> Le dimanche 31 août 2008 à 14:13 +0100, Neil Williams a écrit :
> > Sorry, that is just tosh. If you want to load the glade file via Glade,
> > you keep the XML, depend on libglade and call libglade at runtime.
> 
> You don’t need libglade anymore, GTK+ has integrated the functionality
> since 2.12.

Even better - thanks for that.

Is there likely to be a release goal for Lenny+1 to drop libglade
completely? I find 290 packages depending on libglade2-0.

http://library.gnome.org/devel/gtk/2.11/gtk-migrating-GtkBuilder.html

I'll be using that for one my own upstream projects.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: 25+2 packages with (Glade) generated C source files without the source

[Sami Liedes]

On Sun, Aug 31, 2008 at 02:13:21PM +0100, Neil Williams wrote:
> Of course it does! Once the functionality is dropped, there is no way to
> continue working on the project without editing the C files. Developers
> cannot continue using the old version of glade (it doesn't support some
> of the stuff that you can do with glade).
[...]

Ok, thanks for the explanation, I now see the situation much more
clearly.

Heh, I'm starting to see why lawyers are generally not liked (or at
least that's the cliché), especially when they eventually turn out to
be mistaken, although the response to this issue has been quite nice
and polite this time, and specifically I don't mean this as a
criticism to any of you.

I guess from a maintainer's POV it's quite easy to see efforts like
this as trying to cripple the software or distribution they maintain,
while I view it more like I want to help Debian maintain their
self-chosen commitment to 100% freedom, since freedom is one of the
issues close to my heart. (If you search for bugs reported by me, I
think you'll see that not all of them are nagging for license issues
:)

Thanks for your efforts, all of you!

Sami


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 25+2 packages with (Glade) generated C source files without the source

[Josselin Mouette]

Le dimanche 31 août 2008 à 14:13 +0100, Neil Williams a écrit :
> Sorry, that is just tosh. If you want to load the glade file via Glade,
> you keep the XML, depend on libglade and call libglade at runtime.

You don’t need libglade anymore, GTK+ has integrated the functionality
since 2.12.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: 25+2 packages with (Glade) generated C source files without the source

[Changwoo Ryu]

2008-08-31 (일), 14:56 +0100, Neil Williams:
> On Sun, 2008-08-31 at 15:27 +0200, Josselin Mouette wrote:
> > Le dimanche 31 août 2008 à 14:13 +0100, Neil Williams a écrit :
> > > Sorry, that is just tosh. If you want to load the glade file via Glade,
> > > you keep the XML, depend on libglade and call libglade at runtime.
> > 
> > You don’t need libglade anymore, GTK+ has integrated the functionality
> > since 2.12.
> 
> Even better - thanks for that.
> 
> Is there likely to be a release goal for Lenny+1 to drop libglade
> completely? I find 290 packages depending on libglade2-0.

I don't think so. That work is beyond the scope of Debian packaging or
distribution. Migration needs serious GTK+ programming skill. Even
upstream GNOME has not decided the migration as a release goal for
several releases.

http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder


-- 
Changwoo Ryu <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: Unsafe storage device unmounting

[Ron Johnson]

On 08/31/08 08:47, Neil Williams wrote:

On Sun, 2008-08-31 at 13:51 +0200, Cesare Leonardi wrote:

Cesare Leonardi wrote:

In May i've sent the following mail to debian-gtk-gnome to signal this
problem but since nothing happened so far, i file a bug:

-
Since some days i've noted (updated Debian Sid) that when i right-click
on a usb stick icon and select "Unmount volume", the icon disappear
immediately but the unmount progress window doesn't appear and the
device is still mounted for some seconds.


Have you disabled dbus notifications? The point at which the icon
disappears is not the point at which the drive is safe to remove. DBus
normally raises a notification window "Data is being written to the
device" followed by "Device is now safe to remove".


How does one check whether dbus notification is enabled?

--
Ron Johnson, Jr.
Jefferson LA  USA

"Do not bite at the bait of pleasure till you know there is no
hook beneath it."  -- Thomas Jefferson


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Unsafe storage device unmounting

[Neil Williams]

On Sun, 2008-08-31 at 11:57 -0500, Ron Johnson wrote:
> > 
> > Have you disabled dbus notifications? The point at which the icon
> > disappears is not the point at which the drive is safe to remove. DBus
> > normally raises a notification window "Data is being written to the
> > device" followed by "Device is now safe to remove".
> 
> How does one check whether dbus notification is enabled?

Checking that dbus itself is working - whether the wastebasket shows as
full after deleting a file in nautilus, 'ps waux | grep dbus', 'dpkg -l
notification-daemon', whether other applications like Rhythmbox are able
to show notifications when configured to do so.

The original bug report #433211 does not include the usual list of
dependencies and versions so basic things like this cannot be checked,
possibly because the bug was filed direct from t'bird instead of using a
bug reporting tool.

Cesare, please use reportbug to generate the usual list of dependencies
for the program you think is responsible for this bug then send that
list to the bug report. Thanks.



-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: Unsafe storage device unmounting

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Many times i've observed that the cache sync to the usb pen drive 
> happens *after* the disk icon has disappeared from Gnome desktop, in 
> particular with FAT32 filesystem (seems that cache flush are much more 
> fast on FAT16).

This is especially bad with USB harddisks, those tend to buffer the data
quite long before writing it out.

> For safety now i use to:
> - unmount the disk right-clicking on it;

You can however simply use the umount in terminal window in the first place :)

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#497304: general: packages cannot be partially installed

[Mark Hobley]

Package: general
Severity: wishlist


There is an annoying flaw in the design of the Debian package management 
system, which means that packages cannot be partially installed. This 
limits the flexibility of Debian based systems when it comes to mixed 
installations or installation on embedded or resource constrained 
systems.

For any particular package, the full set of binary components, optional
documentation, and unused foreign language support files will be installed
by the package management system.

This flaw also means that components of bundled packages, such as the 
coreutils suite cannot be individually selected or omitted. This is 
particularly annoying if the system installer wants to replace one of 
the components with a customized version.

A fix would be to make it possible to select individual files for 
installation from within a package.

Other work includes splitting packages into daughter packages, the 
parent package being dependent on all daughters, but allowing the option 
of just selecting individual daughter packages,

eg: coreutils depends on coreutils-fileutils and
coreutils-fileutils depends on coreutils-fileutils-head, 
coreutils-fileutils-split

etc, etc.

Possibly introduce a packaging policy (this is a draft):

Each stand alone binary file should be individually packaged, rather 
than bundled with other stand alone binary files.

It is policy that internationalized (non-english) components are 
packaged separately to the core package. For example, a package foobar, 
would have its french documentation in a separate foobar-fr package.

Packages should not install cruft on the system. This means that a 
package should not install a foreign language file, unless the system 
has been explicitly configured to support that foreign language.

Mark.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-486
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#497304: general: packages cannot be partially installed

[Ben Hutchings]

On Sun, 2008-08-31 at 19:08 +0100, Mark Hobley wrote:
> There is an annoying flaw in the design of the Debian package management 
> system, which means that packages cannot be partially installed. This 
> limits the flexibility of Debian based systems when it comes to mixed 
> installations or installation on embedded or resource constrained 
> systems.

This is being partly addressed by the Emdebian project and the future
introduction of 'tdebs' (translation packages).

The more general feature is 'classes' 
and this may be implemented some day, but don't hold your breath.  I've
merged this bug with earlier similar requests.

Ben.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#497304: general: packages cannot be partially installed

[Eugene V. Lyubimkin]

Mark Hobley wrote:
> For any particular package, the full set of binary components, optional
> documentation, and unused foreign language support files will be installed
> by the package management system.
You are not right, general. Packages are often splitted.

> A fix would be to make it possible to select individual files for 
> installation from within a package.
... and allow user or admin to break whole system by selecting half of 
coreutils and 2/3
files of dpkg. Great.

> Other work includes splitting packages into daughter packages, the 
> parent package being dependent on all daughters, but allowing the option 
> of just selecting individual daughter packages,
> 
> eg: coreutils depends on coreutils-fileutils and
> coreutils-fileutils depends on coreutils-fileutils-head, 
> coreutils-fileutils-split
$ dpkg -L coreutils | grep bin | wc -l
99
And you suggest package all these binaries individually? Did you think about 
size of dpkg
and apt databases, if you tell about embedded systems?

> It is policy that internationalized (non-english) components are 
> packaged separately to the core package. For example, a package foobar, 
> would have its french documentation in a separate foobar-fr package.
Please, have a look on repository and wonder. If some package bundles _big_ 
piece of stuff
all-at-one, you should file a wishlist bug against this package, not general.

> Packages should not install cruft on the system. This means that a 
> package should not install a foreign language file, unless the system 
> has been explicitly configured to support that foreign language.
So, If I need Japanese support in browser I have to install all available 
Japanese stuff
related to other thousand of packages?

I have almost no doubt this report should be marked 'wontfix'.

-- 
Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer.



signature.asc
Description: OpenPGP digital signature

Bug#497304: general: packages cannot be partially installed

[Neil Williams]

On Sun, 2008-08-31 at 19:08 +0100, Mark Hobley wrote:
> Package: general
> Severity: wishlist
> 
> 
> There is an annoying flaw in the design of the Debian package management 
> system, which means that packages cannot be partially installed. 

Umm, yes they can actually. Emdebian uses this functionality all the
time. You have a choice of unpacking and running the preinst maintainer
scripts or you can extract the package to a local directory or you can
view the contents of the package with dpkg -c, dpkg -I or deb-gview,
there are quite a few methods.

> For any particular package, the full set of binary components, optional
> documentation, and unused foreign language support files will be installed
> by the package management system.

This is dpkg filtering which is also being implemented - I looked at a
version at DebConf7 due to needs within Emdebian and it has since been
enhanced and being implemented in dpkg.

> This flaw also means that components of bundled packages, such as the 
> coreutils suite cannot be individually selected or omitted. This is 
> particularly annoying if the system installer wants to replace one of 
> the components with a customized version.

Filtering would support that too.

> A fix would be to make it possible to select individual files for 
> installation from within a package.
> 
> Other work includes splitting packages into daughter packages, the 
> parent package being dependent on all daughters, but allowing the option 
> of just selecting individual daughter packages,

Currently, that means rebuilding the packages - Emdebian is doing that
too.

> Each stand alone binary file should be individually packaged, rather 
> than bundled with other stand alone binary files.

Umm, we have 20,000 packages - that could push us to 2 million
overnight. I don't think ftp-master would accept that.

> It is policy that internationalized (non-english) components are 
> packaged separately to the core package. For example, a package foobar, 
> would have its french documentation in a separate foobar-fr package.

TDebs will implement this - support is planned in the infrastructure for
Lenny+1 and in packages for Lenny+2

> Packages should not install cruft on the system. This means that a 
> package should not install a foreign language file, unless the system 
> has been explicitly configured to support that foreign language.

A combination of dpkg filtering, an Emdebian TDeb utility to be merged
into apt and other infrastructure support is already planned for this
scenario.


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Bug#497308: ITP: libhttp-server-simple-static-perl -- Serve static files with HTTP::Server::Simple

[Jaldhar H. Vyas]

Package: wnpp
Severity: wishlist
Owner: "Jaldhar H. Vyas" <[EMAIL PROTECTED]>

* Package name: libhttp-server-simple-static-perl
  Version : 0.07
  Upstream Author : Stephen Quinney <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/HTTP-Server-Simple-Static/
* License : GPL + Artistic
  Programming Lang: Perl
  Description : Serve static files with HTTP::Server::Simple

This mixin adds a method to serve static files from your HTTP::Server::Simple
subclass.

[ I am packaging this as it is a dependency of libcgi-application-server-perl.
It will be maintained via the pkg-perl group.]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: reassign 497304 to dpkg, forcibly merging 68788 497304

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.29~bpo40+1
> reassign 497304 dpkg
Bug#497304: general: packages cannot be partially installed
Bug reassigned from package `general' to `dpkg'.

> forcemerge 68788 497304
Bug#68788: --without-docs option for dpkg
Bug#497304: general: packages cannot be partially installed
Bug#68861: dpkg should have a way to throw out subtrees from packages
Forcibly Merged 68788 68861 497304.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Live Lenny Beta1

[Jerome BENOIT]

Hello List,

Daniel Baumann wrote:

Daniel Baumann wrote:

Nevertheless, we do need your help to find more bugs and improve the
live systems, so please try them out.


particulary interesting would be to get reports from people with
Intel-based Apple hardware (both notebooks and desktops).


I have just tried the Standard one o my (old) Black MacBook:
because of the keyboard freezing issue, I could not start it :-)

Cheers,
Jerome



Regards,
Daniel



--
Jerome BENOIT
jgmbenoit_at_mailsnare_dot_net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#497304: general: packages cannot be partially installed

[Steve Greenland]

On 31-Aug-08, 13:08 (CDT), Mark Hobley <[EMAIL PROTECTED]> wrote: 
> Packages should not install cruft on the system. This means that a 
> package should not install a foreign language file, unless the system 
> has been explicitly configured to support that foreign language.

Others have commented on your general points, but there is a solution 
to this one:

apt-get install localepurge

They still get installed, but then immediately removed. Quite hacky,
admittedly.

Steve


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 1 of 400 dpkg databases corrupt?

[Enrico Zini]

On Sat, Aug 23, 2008 at 04:32:46AM +0200, Petter Reinholdtsen wrote:

> Looking at
> http://qa.debian.org/popcon.php?package=popularity-contest >, I
> see that only 99.75% of the machines reporting to popcon.debian.org
> have the package popularity-contest installed.  As this is impossible,
> I suspect this mean that 0.25% (1 of 400) of the machines reporting to
> popcon.debian.org got a corrupt/inconsitent dpkg database.  Is this an
> acceptable ratio?  Anything we can do to reduce the number of machines
> with corrupt dpkg database?

Could it be a case of machines that nfs-mount /etc and /usr, but not
/var, or machines updated by rsyncing /etc and /usr?


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Bug#497316: general: Building entire system from source

[Mark Hobley]

Package: general
Severity: wishlist


It would be nice to have the option of using a binary or source based 
distribution built from Debian sources.

Ideally, a live CD, could be used to build the entire base system from source
by simply specifying the source repository to be used.

The system could then be configured to allow source builds of all 
additional packages.

Mark.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-486
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#496967: general: System completely blocks any input

[Daniel Burrows]

On Sat, Aug 30, 2008 at 12:21:16PM +0200, Frank Küster <[EMAIL PROTECTED]> was 
heard to say:
> Is there any live system available which can handle lvm volumes? I think 
> I even have some free disk space for an additional partition to install 
> the live system on harddisk. But I cannot access it from Knoppix, and 
> didn't find information on lvm in the Knoppix FAQ.

  I haven't tried it, but I would expect that the Ubuntu live CD has
the necessary support.  e.g., this article says it works if you install
the lvm user-space tools in the live system:

http://linuxwave.blogspot.com/2007/11/mounting-lvm-disk-using-ubuntu-livecd.html

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#497316: marked as done (general: Building entire system from source)

[Debian Bug Tracking System]

Your message dated Sun, 31 Aug 2008 23:12:42 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#497316: general: Building entire system from source
has caused the Debian Bug report #497316,
regarding general: Building entire system from source
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
497316: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497316
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: general
Severity: wishlist


It would be nice to have the option of using a binary or source based 
distribution built from Debian sources.

Ideally, a live CD, could be used to build the entire base system from source
by simply specifying the source repository to be used.

The system could then be configured to allow source builds of all 
additional packages.

Mark.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-486
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash


--- End Message ---
--- Begin Message ---
Hi,

On Sunday 31 August 2008 22:24, Mark Hobley wrote:
> It would be nice to have the option of using a binary or source based
> distribution built from Debian sources.

go ahead, see simple-cdd.

> Ideally, a live CD, could be used to build the entire base system from
> source by simply specifying the source repository to be used.

go ahead, build one, see live-helper.

Closing this bugreport, as there is no bug. For discussing ideas, you dont 
need to file bugs. For implementing them, neither. (Well, unless you reach 
the state of an ITP.)


regards,
Holger


pgpmfdh4WaGPz.pgp
Description: PGP signature
--- End Message ---

Re: Source field in binary Packages list

[Daniel Burrows]

On Sat, Aug 30, 2008 at 07:13:50PM -0300, Thadeu Lima de Souza Cascardo <[EMAIL 
PROTECTED]> was heard to say:
> On Sat, Aug 30, 2008 at 03:21:36PM -0500, Raphael Geissert wrote:
> > Thadeu Lima de Souza Cascardo wrote:
> > 
> > > Hello,
> > > 
> > > I am working on a grouping feature for aptitude, to group binary
> > > packages by their source package. However, some packages in the Packages
> > > file do not have a Source field. My guess was to use the package name as
> > > the source package name. Is this right?
> > 
> > Yup
> > 
> > > 
> > > Thanks,
> > > Thadeu Cascardo.
> 
> Thanks again!
> 
> For those interested, I've submitted the patches to the BTS as bugs
> 497205 and 497206. Note that 497205 should break libapt-pkg ABI, so take
> care.  :-)

  Why do you need #497205?  Is it too slow to just use SourcePkg() in
the package records object?

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#497316: general: Building entire system from source

[Neil Williams]

On Sun, 2008-08-31 at 21:24 +0100, Mark Hobley wrote:
> Package: general
> Severity: wishlist
> 
> 
> It would be nice to have the option of using a binary or source based 
> distribution built from Debian sources.

Bearing in mind your previous bug report, I really think you should be
looking at Emdebian and asking these questions on the debian-embedded
mailing list - we're doing all this stuff. You will have to do 90% of
the work yourself but that's inevitable (see below). At least Emdebian
can provide the tools and infrastructure to get the job done - mainly
because we are doing it ourselves.

> Ideally, a live CD, could be used to build the entire base system from source
> by simply specifying the source repository to be used.

Umm, just how are you going to fit the system and the source on a CD?
You might with an Emdebian system that has a GUI in 75Mb but probably
not a full Debian install + source. I don't know how big the source
would be for the current Emdebian GUI but my current Emdebian build tree
has only 240 source packages and takes up 9.2Gb for a single
architecture. (Yes, that is a build tree as opposed to a directory
containing compressed source packages but it does give an indication of
the possible scale.) That doesn't even count the build-dependencies that
are installed. Yes, it really can take 9.2Gb to create a binary distro
of 75Mb. That is most definitely not a typo. GlibC, GCC, Xorg, they are
all v.big source packages.

With the full build environment and sources and various other
components, I think you could create a CD but note that this is *you*
creating it. I cannot see that Debian would provide such a CD for you -
at least not until Emdebian has done a whole lot more work on the Debian
infrastructure. Customisation includes bespoke patches and full control
over package selection (including dropping perl and Essential) but you
will have to do 90% of the work yourself. The tools exist, feel free to
use them - just do ask your questions on
[EMAIL PROTECTED] instead of filing general bugs (which
all get CC'd to debian-devel and which can end up annoying people when
you start asking for stuff that is just "out-there" when it comes to how
Debian normally works - especially this close to a release). If you want
to change Debian to work with small systems and embedded systems,
debian-embedded is the place to be - not bugs.debian.org and not
debian-devel (at least until Lenny is released).

FYI the problems with what you require come in several stages:
1. Package selection - how much are you building? For embedded stuff,
you want very tight control over this.
2. Build sequencing - which ones do you build first? Entirely determined
by your choices under Q1 but plotting your path through the dependencies
such that the build-dependencies of foo are available when you need to
build foo to build bar - without finding that bar build-depends on baz
which you haven't built yet, and so on.
3. You cannot decide on what sources to put on the media until you have
solved Q1 and Q2. You cannot know if they will fit until you've answered
Q3.

Now there are tools that can help with this process (mancoosi are
working on things like that and others already exist) but there is no
one-size-fits-all solution, especially for embedded stuff. Then you run
into problem 4:

4. Once you've done it, you don't need to work out how to do it again so
the optimisation never happens and each process is just as much work as
the last. Packages change, build-depends change, by the time you've done
one, the whole path can be radically different.

Yes, I have done Q1, Q2, Q3 and Q4 for Emdebian ARM. It took the best
part of a year.

> The system could then be configured to allow source builds of all 
> additional packages.

Already done - and if you use the existing Emdebian support, the
distribution can be entirely cross-built from source too. You just need
to do the work yourself.

P.S. I would reassign this bug but I'm waiting for the pseudo-package
for Emdebian that would perfectly suit this bug report. (hint!)
:-)

(I know everyone at ftpmaster is out-of-their-minds-busy right now but
it would take this traffic off -devel if the pseudo-package was
available . . . )

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part

Re: Unsafe storage device unmounting

[Cesare Leonardi]

Neil Williams wrote:

Have you disabled dbus notifications? The point at which the icon
disappears is not the point at which the drive is safe to remove. DBus
normally raises a notification window "Data is being written to the
device" followed by "Device is now safe to remove".


Mmh, i feel you are near to the problem even if...
No, i've not disabled dbus notification neither i've ever tweaked it.
Moreover "notification-daemon" is installed, i can see notification 
messages from other apps like Rhythmbox and the trashcan icon change 
depending on its full/empty status.


From my first mail to debian-gtk-gnome (May 2007), i have never seen 
any notification after clicking on "Unmount volume".
I use unstable since 2005: maybe there are some conffile that was not 
updated correctly, in particular when the progress bar taken from Ubuntu 
was removed.
By the way, good to know how a good working Gnome environment should 
behave.  :-)


As you asked in another mail, i append the information collected by 
"reportbug gnome" (quoted to avoid Thunderbird to wrap lines):

---

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages gnome depends on:
ii  arj3.10.22-6 archiver for .arj files
ii  avahi-daemon   0.6.23-2  Avahi mDNS/DNS-SD daemon
ii  bluez-gnome0.27-1Bluetooth utilities for GNOME
ii  epiphany-extensions2.22.2-1  Extensions for Epiphany web browse
ii  evolution-exchange 2.22.3.dfsg-1 Exchange plugin for the Evolution 
ii  evolution-plugins  2.22.3.1-1standard plugins for Evolution
ii  evolution-webcal   2.21.92-1 webcal: URL handler for GNOME and 
ii  gdm-themes 0.6   Themes for the GNOME Display Manag

ii  gnome-app-install  0.5.5.1-1 GNOME Application Installer
ii  gnome-desktop-environment  1:2.22.2~4The GNOME Desktop Environment
ii  gnome-games1:2.22.3-2games for the GNOME desktop
ii  gnome-spell1.0.7-1   GNOME/Bonobo component for spell c
ii  gnome-themes-extras0.9.0.deb0.4  various themes for the GNOME 2 des
ii  gnome-vfs-obexftp  0.4-1 GNOME VFS module for OBEX FTP
ii  gstreamer0.10-ffmpeg   0.10.4-3  FFmpeg plugin for GStreamer
ii  gstreamer0.10-plugins-ugly 0.10.8-1  GStreamer plugins from the "ugly" 
ii  libpam-gnome-keyring   2.22.3-1  PAM module to unlock the GNOME key

ii  p7zip  4.58~dfsg.1-1 7zr file archiver with high compre
ii  rhythmbox  0.11.6-1  music player and organizer for GNO
ii  serpentine 0.9-5 An application for creating audio 
ii  swfdec-mozilla 0.6.0-4   Mozilla plugin for SWF files (Macr

ii  synaptic   0.62.1Graphical package manager
ii  system-config-printer  1.0.0-2   graphical interface to configure t
ii  totem-mozilla  2.22.2-3  Totem Mozilla plugin
ii  transmission-gtk   1.33-1free, lightweight BitTorrent clien

Versions of packages gnome recommends:
pn  empathy | pidgin   (no description available)
pn  gdebi  (no description available)
ii  gnome-games-extra-data2.22.0-1   games for the GNOME desktop (extra
ii  gnome-office  1:2.22.2~4 The GNOME Office suite
ii  gparted   0.3.8-1+b1 GNOME partition editor
ii  gthumb3:2.10.8-1 an image viewer and browser
ii  hal-cups-utils0.6.16-2   Utilities to detect and configure 
ii  hardinfo  0.4.2.3-5  Displays system information

pn  liferea | blam (no description available)
ii  menu-xdg  0.3freedesktop.org menu compliant win
pn  network-manager-gnome  (no description available)
ii  tomboy0.10.2-1   desktop note taking program using 
ii  tsclient  0.150-1front-end for viewing of remote de

pn  update-notifier(no description available)

Versions of packages gnome suggests:
pn  gnome-dbg  (no description available)
pn  openoffice.org-evolution   (no description available)
ii  openoffice.org-gnome  1:2.4.1-8  GNOME Integration for OpenOffice.o

-- no debconf information

---

Many thanks for your help.
Regards.

Cesare.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Source field in binary Packages list

[Thadeu Lima de Souza Cascardo]

On Sun, Aug 31, 2008 at 02:20:27PM -0700, Daniel Burrows wrote:
>   Why do you need #497205?  Is it too slow to just use SourcePkg() in
> the package records object?
> 
>   Daniel

Sorry! I was lazy/stupid/whatever enough to not read more about apt and
learn how to do it without adding a field to the cache. So, I am
attaching the patch to the patch for aptitude, which does not need this
other patch to APT. I will close the apt bug after that.

I still like the patch to be reviewed, if you can, please.

Thanks,
Thadeu Cascardo.
diff -u aptitude-0.4.11.8/src/pkg_grouppolicy.cc aptitude-0.4.11.8/src/pkg_grouppolicy.cc
--- aptitude-0.4.11.8/src/pkg_grouppolicy.cc
+++ aptitude-0.4.11.8/src/pkg_grouppolicy.cc
@@ -1676,11 +1676,11 @@
 
   void add_package(const pkgCache::PkgIterator &pkg, pkg_subtree *root)
   {
-string source;
-if (!pkg.Source())
+if (pkg.VersionList().end() || pkg.VersionList().FileList().end())
+  return;
+string source=apt_package_records->Lookup(pkg.VersionList().FileList()).SourcePkg();
+if (source.length()==0)
   source=pkg.Name();
-else
-  source=pkg.Source();
 
 childmap::iterator found=children.find(source);
 


signature.asc
Description: Digital signature

Re: Bug#497236: ITP: libcpuset -- assigns a set of CPUs and Memory Nodes to a set of tasks

[Paul Jackson]

Bastian wrote:
> Does it work with the cgroup subsystem?

I'm uncertain of the context here, as I don't usually
read this list, and don't have the prior messages on
this particular thread, but if you're asking if libcpuset
works with cgroups, yes it does.

The cgroup subsystem does not change cpusets at all.
Cpusets "post-cgroups" are 100% compatible with cpusets
"pre-cgroups."

The documentation is two years old because cpusets has
been stable for that long.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#496967: general: System completely blocks any input

[Alexander Wirt]

Frank Küster schrieb am Saturday, den 30. August 2008:

Hi, 

*snip*
> Is there any live system available which can handle lvm volumes? I think 
> I even have some free disk space for an additional partition to install 
> the live system on harddisk. But I cannot access it from Knoppix, and 
> didn't find information on lvm in the Knoppix FAQ.
grml [1] has support for lvm. Just start it via /etc/init.d/lvm start after
booting. 

Alex

[1] http://www.grml.org/




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#497236: ITP: libcpuset -- assigns a set of CPUs and Memory Nodes to a set of tasks

[Aníbal Monsalve Salazar]

On Sun, Aug 31, 2008 at 10:37:01PM -0500, Paul Jackson wrote:
>Bastian wrote:
>>Does it work with the cgroup subsystem?
>
>I'm uncertain of the context here, as I don't usually read this list,
>and don't have the prior messages on this particular thread,

http://lists.debian.org/debian-devel/2008/08/msg00871.html

>but if you're asking if libcpuset works with cgroups, yes it does.
>
>The cgroup subsystem does not change cpusets at all.  Cpusets
>"post-cgroups" are 100% compatible with cpusets "pre-cgroups."
>
>The documentation is two years old because cpusets has been stable for
>that long.
>
>-- 
>  I won't rest till it's the best ...
>  Programmer, Linux Scalability
>  Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214


signature.asc
Description: Digital signature