headers
Cesare Leonardi | 1 Sep 04:08
Picon
Favicon

Re: Unsafe storage device unmounting

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)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thadeu Lima de Souza Cascardo | 1 Sep 05:57

Re: Source field in binary Packages list

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.
Attachment (aptitude2.diff): text/x-diff, 655 bytes
Permalink | Reply | 0 comments |
headers
Paul Jackson | 1 Sep 05:37
Picon
Favicon

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

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 <pj <at> sgi.com> 1.940.382.4214
Permalink | Reply | 2 comments |
headers
Alexander Wirt | 1 Sep 08:07
Picon
Favicon

Bug#496967: general: System completely blocks any input

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/
Permalink | Reply | 0 comments |
headers
Aníbal Monsalve Salazar | 1 Sep 08:54
Picon
Favicon

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

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 <pj <at> sgi.com> 1.940.382.4214
Permalink | Reply | 1 comment |
headers
Paul Jackson | 1 Sep 08:59
Picon
Favicon

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

Anibal, replying to pj:
> > 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

Yeah - so I figured out.  Thanks.

--

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj <at> sgi.com> 1.940.382.4214
Permalink | Reply | 0 comments |
headers
Lucas Nussbaum | 1 Sep 09:06

Re: automatic bug filing by test robot

On 28/08/08 at 09:19 +0200, Raphael Hertzog wrote:
> On Wed, 27 Aug 2008, Ian Jackson wrote:
> > I'm hoping to shortly turn on the automatic bug filing mechanism.
> > I'm writing now to give people a chance to object :-).
> [...]
> > very few other packages.  Most autopkgtest reports are FTBFS problems.
> 
> I object filing FTBFS automatically. In some cases, the FTBFS is a failure
> from one of the build-dependencies and filing bugs automatically would
> lead to lots of useless/duplicate bugs. Thus a I think that a human filter
> here is most welcome.
> 
> Lucas is covering this quite well up to now. If we ever get back to the
> situation where nobody is willing to do that work, then we can reconsider
> this. Also, how would you check that a bug has not already been filed
> manually by another user?

What I do with my archive rebuilds is:
- rebuild everything (it's important to process results only when you
  have all the results for all packages, as it makes it easier to find
  failures caused by a change in another package)
- have a script extract the failures from all logs, so I can easily get
  an overview of all the failures, making it easier to find a regression
  in some common tool that caused dozens of new failures.
- for each remaining package, use the BTS SOAP interface the fetch all
  the bugs, and filter the bugs using a regexp (basically
  /(ftbfs|build)/ ), so I avoid most of the potential duplicates.
- before filing the bug (using a script), list the possibly relevant
  bugs from the package.
- usertag the bugs, so I can easily keep track of:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lucas Nussbaum | 1 Sep 09:11

Re: automatic bug filing by test robot

On 27/08/08 at 22:10 +0100, Ian Jackson wrote:
> Also, if you have any comments about the format of the email,
> supporting references, etc., that would be helpful.

I think that we have a problem with the way we export data from
automated tests. Consensus is (I think) that bugs should not be filed
automatically, unless the person filing the bugs is reasonably sure of
the validity of the bugs, the lack of duplicate bugs, etc. I agree with
that.

Maybe you should focus on providing the data in a machine-parseable
format, and write a seperate tool that would allow to gather data from
all the tests we are running (I can think of lintian and piuparts, at
least), and display all the results on a nice web page, with all the
cool features one can think of.

So far, everybody has been reinventing the wheel, and that results in
http://piuparts.cs.helsinki.fi/ and http://lintian.debian.org/.
--

-- 
| Lucas Nussbaum
| lucas <at> lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas <at> nussbaum.fr             GPG: 1024D/023B3F4F |
Permalink | Reply | 3 comments |
headers
Johann Spies | 1 Sep 10:23
Picon
Picon
Favicon

Re: Debian Live Lenny Beta1

On Mon, Sep 01, 2008 at 03:31:23AM +0800, Jerome BENOIT wrote:
> 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).
>

Do you want feedback on these lists?  I have tried the bugreport
system, but that seems to work with packages. How do I submit
bugreports on the debian-live-cd?

I have tried the amd64-version on a Lenovo R61 as well as on my
Macbook.  Maybe I should try the i386 on the Macbook because it did
not boot properly and I could not use the keyboard.

On the R61 I could not get my wifi working.  The Fn-F8 key also did
not work.  I did not test it fully.  Here is an some of the
output of dmesg:

[   64.897496] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.23ks
[   64.897597] iwl3945: Copyright(c) 2003-2007 Intel Corporation
[   64.897807] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
[   64.897992] PCI: Setting latency timer of device 0000:03:00.0 to 64
[   64.898018] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[   64.961632] iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Wise | 1 Sep 11:04
Picon
Favicon
Gravatar

Re: Debian Live Lenny Beta1

On Mon, Sep 1, 2008 at 4:23 PM, Johann Spies <jspies <at> sun.ac.za> wrote:

> On the R61 I could not get my wifi working.
>  Here is an some of the output of dmesg:
> [   64.897496] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.23ks

You have wireless hardware that requires non-free firmware to be
installed on the wifi chip. You need to enable the non-free section
and install the non-free firmware-iwlwifi package. This isn't specific
to debian-live.

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
Permalink | Reply | 1 comment |

Gmane