FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-16-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 4 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 4 fully signed off packages
* 18 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (4 total) ==

* glib2-2.32.3-1 (i686)
* glib2-2.32.3-1 (x86_64)
* openmpi-1.6-1 (i686)
* openmpi-1.6-1 (x86_64)


== Incomplete signoffs for [core] (10 total) ==

* cryptsetup-1.4.2-1 (i686)
0/2 signoffs
* glib2-2.32.3-1 (i686)
1/2 signoffs
* isdn4k-utils-3.22_20120509-1 (i686)
0/2 signoffs
* iw-3.4-1 (i686)
0/2 signoffs
* libnl-3.2.9-1 (i686)
1/2 signoffs
* mdadm-3.2.4-1 (i686)
0/2 signoffs
* xinetd-2.3.15-1 (i686)
1/2 signoffs
* glib2-2.32.3-1 (x86_64)
0/2 signoffs
* isdn4k-utils-3.22_20120509-1 (x86_64)
0/2 signoffs
* xinetd-2.3.15-1 (x86_64)
1/2 signoffs

== Incomplete signoffs for [extra] (8 total) ==

* hwloc-1.4.2-1 (i686)
0/2 signoffs
* misdnuser-2.0.13_20120513-1 (i686)
0/2 signoffs
* openmpi-1.6-1 (i686)
0/2 signoffs
* xorg-server-1.12.1.901-2 (i686)
0/2 signoffs
* hwloc-1.4.2-1 (x86_64)
0/2 signoffs
* misdnuser-2.0.13_20120513-1 (x86_64)
0/2 signoffs
* openmpi-1.6-1 (x86_64)
0/2 signoffs
* xorg-server-1.12.1.901-2 (x86_64)
1/2 signoffs


== Completed signoffs (4 total) ==

* cryptsetup-1.4.2-1 (x86_64)
* iw-3.4-1 (x86_64)
* libnl-3.2.9-1 (x86_64)
* mdadm-3.2.4-1 (x86_64)


== Top five in signoffs in last 24 hours ==

1. allan - 1 signoffs
2. ibiru - 1 signoffs
 
Old 05-17-2012, 04:16 AM
Steven J Long
 
Default

Greg KH wrote:
> Steven J Long wrote:
>> And that is what we were discussing: possible future coupling between the
>> two, which is much easier to do when the sources are part of the
>> same package.
..
>> OFC you could just assure us that udev will never rely on systemd as a
>> design decision. I can understand that systemd might need close
>> integration with the underlying udev implementation.
>
> Nope, can't make that assurance at all.
>
> Actually, maybe I can make the opposite assurance

Well, thanks for being straightforward about it: clearly you're keeping the
option of udev requiring systemd open, and in fact want to move toward that.

> , let's see what the future brings...
>
Yeah, we'll see You have udev working nicely, fulfilling a whole load of
use-cases, and now you want to upwardly-couple to er, a service-manager.
Running as pid 1, no less, even though it's not necessary. (I predict that
latter decision will get reversed in a while, just like a /usr partition
went from an anachronism to a grand new design, and xml config formats are
no longer talked about; thankfully binary logs got slammed back out the door
in-kernel at least[1].)

Not build another thing utilising udev and dbus, not even one closely
integrated, but upwardly-couple every Linux system to that new userspace
project. Good luck with that.

steveL.

[1] http://lwn.net/Articles/492134/
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 05-17-2012, 04:39 AM
Steven J Long
 
Default

Alec Warner wrote:

> Fabio Erculiani <lxnay@gentoo.org> wrote:
>> I think expressing my own opinion about Lennart-made software is my
>> right, after all.
>> Firstly, it's almost impossible nowadays to avoid including avahi,
>> systemd and pulseaudio into a desktop distro so, there is no real
>> choice. This issue became a sensible matter for those users who for
>> instance, wanted to have a silly mp3 player working without going
>> through the PA nonsense, really missing the old
>> ALSA-oh-it-was-always-working days.
>
> Er, the source is open, so choice is always there. What I think your
> complaint is the fact that it used to be easy to do those things
> (because upstream supported those options and USE flags exposed them
> to you) and now upstream is not supporting those options and there is
> no easy way to remove the dependencies without doing a bunch of work.
>
I think it's more a matter of process. These changes force major userspace
changes, which since they are not a matter of ABI export, don't really
concern kernel devs (after all, they design for userspace to do crazy stuff,
or their OS is not robust: beyond ABI stability, the contract they fulfil,
in the main they don't really care what happens there.)

However the changes are forced on admins and users, unless we take on a
development effort which means we're no longer just admins or users. And
yeah, people are clearly looking at doing that with mdev, though we'd rather
not have to be forced into that.

>> If you want to bring complexity but you end up not being able to
>> handle it, then you're not a really good engineer, IMHO.
>
> I don't think anyone expects complexity to come bug-free. Cathedral
> and the Bazaar? Release Early and Release Often? I expect the software
> to reach a stable state in a reasonable amount of time given the
> complexity involved.
>
The way to handle complexity is with small, modular components that are
loosely-coupled and cohesive. AKA "Do one thing, and do it well." Like udev
has been doing for quite a while.

>>
>> Having said that, I also wonder where's the lovely modularity the
>> various *nix platforms had. If this is the actual direction of Linux
>> Foundation, Redhat and Canonical, I am worried that Linux would end up
>> being an OSX-wannabe.
>
> The problem as I understand it is that you want other people to write
> software that meets your needs and it turns out that the world doesn't
> always work that way.
>
> You can fork the software you hate (using versions before you hated
> it) or you can write your own software (like mdev + busybox) to
> replace the hated components. Both of those things are actually
> somewhat useful. Complaining about how some random people on the
> internet don't write software that you find palatable is just silly.
>
It's not about that: the point is that massive changes are being pushed
through, and the people who actually have to implement them in the real-
world haven't been consulted. When they are, after their concerns about
administration (you know, their jobs) are dismissed and they're asked for
technical reasons, they draw attention to Unix principles, simply because
they have been proven over decades to be the best basis for software-
engineering.

And please: "random people on the internet"? That's not how I'd describe
upstream udev or kernel maintainers. Or is this your "it's the developer's
playground" philosophy again?

Simply put, there is no space in kernel mailing-lists, nor in upstream udev
et al, to have this discussion. It affects Gentoo users most, because we are
far more likely to run using custom-compiled kernels with base system
modules like motherboard disk-controllers built-in, and to have setup eg
/usr on LVM in accordance with docs, and since we use a rolling-release we
haven't needed to change what wasn't broken.

Nor do many of us think we've heard any benefit to outweigh the
disadvantages. For instance, we've been told several times that a) an
initramfs is the new root, in that we don't need rescue tools on an easy to
mount root anymore, our initramfs will be a souped-up rescue-shell; and b)
that an initramfs is easy to set up and maintain, and should typically only
be a few hundred kilobytes (so it's not going to bloat the boot process.)

Everything I've seen of people's configs in forum posts about setting up
initramfs, and heard of the process, makes me think it's going to be a
custom design per-Gentoo user, and tweaking what's in there is going to be
part of standard setup and ongoing maintenance. Forgive me for assessing
that as a regression in usability.

Ultimately of course, udev maintainers will do what they want. That's fine,
and I'll shut up about the whole thing as my concerns are on the record:
just so long as no-one pretends they've justified the breaches of basic
design principles.

Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 05-17-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 2 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 5 packages missing signoffs
* 2 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [community-testing] in last 24 hours (2 total) ==

* libvirt-0.9.12-2 (i686)
* libvirt-0.9.12-2 (x86_64)


== Incomplete signoffs for [community] (3 total) ==

* systemd-arch-units-20120412-5 (any)
0/2 signoffs
* libvirt-0.9.12-2 (i686)
0/2 signoffs
* libvirt-0.9.12-2 (x86_64)
0/2 signoffs

== Incomplete signoffs for [unknown] (2 total) ==

* mariadb-5.5.23-3 (i686)
1/2 signoffs
* mariadb-5.5.23-3 (x86_64)
1/2 signoffs


== All packages in [community-testing] for more than 14 days (2 total) ==

* mariadb-5.5.23-3 (x86_64), since 2012-04-26
* mariadb-5.5.23-3 (i686), since 2012-04-26


== Top five in signoffs in last 24 hours ==

1. foutrelis - 2 signoffs
2. bisson - 1 signoffs
 
Old 05-17-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 4 fully signed off packages
* 12 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)



== Incomplete signoffs for [core] (6 total) ==

* cryptsetup-1.4.2-1 (i686)
0/2 signoffs
* iw-3.4-1 (i686)
0/2 signoffs
* libnl-3.2.9-1 (i686)
1/2 signoffs
* mdadm-3.2.4-1 (i686)
0/2 signoffs
* xinetd-2.3.15-1 (i686)
1/2 signoffs
* xinetd-2.3.15-1 (x86_64)
1/2 signoffs

== Incomplete signoffs for [extra] (6 total) ==

* hwloc-1.4.2-1 (i686)
0/2 signoffs
* openmpi-1.6-1 (i686)
0/2 signoffs
* xorg-server-1.12.1.901-2 (i686)
0/2 signoffs
* hwloc-1.4.2-1 (x86_64)
0/2 signoffs
* openmpi-1.6-1 (x86_64)
0/2 signoffs
* xorg-server-1.12.1.901-2 (x86_64)
1/2 signoffs


== Completed signoffs (4 total) ==

* cryptsetup-1.4.2-1 (x86_64)
* iw-3.4-1 (x86_64)
* libnl-3.2.9-1 (x86_64)
* mdadm-3.2.4-1 (x86_64)


== Top five in signoffs in last 24 hours ==

1. foutrelis - 2 signoffs
2. bisson - 1 signoffs
 
Old 05-18-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 3 packages missing signoffs
* 2 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)



== Incomplete signoffs for [community] (1 total) ==

* systemd-arch-units-20120412-5 (any)
0/2 signoffs

== Incomplete signoffs for [unknown] (2 total) ==

* mariadb-5.5.23-3 (i686)
1/2 signoffs
* mariadb-5.5.23-3 (x86_64)
1/2 signoffs


== All packages in [community-testing] for more than 14 days (2 total) ==

* mariadb-5.5.23-3 (x86_64), since 2012-04-26
* mariadb-5.5.23-3 (i686), since 2012-04-26


== Top five in signoffs in last 24 hours ==

1. allan - 2 signoffs
2. thomas - 1 signoffs
 
Old 05-18-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 11 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 3 fully signed off packages
* 16 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (11 total) ==

* netcfg-2.8.3-1 (any)
* sudo-1.8.5-1 (i686)
* sudo-1.8.5-1 (x86_64)
* openmpi-1.6-2 (i686)
* subversion-1.7.5-1 (i686)
* xf86-video-ati-6.14.99-0.20120517 (i686)
* xorg-server-1.12.1.901-3 (i686)
* openmpi-1.6-2 (x86_64)
* subversion-1.7.5-1 (x86_64)
* xf86-video-ati-6.14.99-0.20120517 (x86_64)
* xorg-server-1.12.1.901-3 (x86_64)


== Incomplete signoffs for [core] (6 total) ==

* netcfg-2.8.3-1 (any)
0/2 signoffs
* cryptsetup-1.4.2-1 (i686)
0/2 signoffs
* mdadm-3.2.4-1 (i686)
0/2 signoffs
* sudo-1.8.5-1 (i686)
1/2 signoffs
* xinetd-2.3.15-1 (i686)
1/2 signoffs
* sudo-1.8.5-1 (x86_64)
1/2 signoffs

== Incomplete signoffs for [extra] (10 total) ==

* hwloc-1.4.2-1 (i686)
0/2 signoffs
* openmpi-1.6-2 (i686)
0/2 signoffs
* subversion-1.7.5-1 (i686)
0/2 signoffs
* xf86-video-ati-6.14.99-0.20120517 (i686)
0/2 signoffs
* xorg-server-1.12.1.901-3 (i686)
0/2 signoffs
* hwloc-1.4.2-1 (x86_64)
0/2 signoffs
* openmpi-1.6-2 (x86_64)
0/2 signoffs
* subversion-1.7.5-1 (x86_64)
0/2 signoffs
* xf86-video-ati-6.14.99-0.20120517 (x86_64)
0/2 signoffs
* xorg-server-1.12.1.901-3 (x86_64)
0/2 signoffs


== Completed signoffs (3 total) ==

* cryptsetup-1.4.2-1 (x86_64)
* mdadm-3.2.4-1 (x86_64)
* xinetd-2.3.15-1 (x86_64)


== Top five in signoffs in last 24 hours ==

1. allan - 2 signoffs
2. thomas - 1 signoffs
 
Old 05-18-2012, 10:06 AM
Arnd Bergmann
 
Default

On Thursday 10 May 2012, Kent Overstreet wrote:
> TODO/known issues:
>
> __up_write() needs to be exported for bcache to compile as a module - it's
> used for bypassing lockdep when traversing the btree during garbage
> collection. If someone else knows a better solution, please let me know.
>
> The userspace interface is going to change before it goes in. The general
> consensus at LSF was that we don't want yet another interface for
> probing/managing block devices, and dm exists so we may as well use that. I
> don't think anyone's started on that yet, though.
>
> Documentation needs to be updated. That's being actively worked on, though.

Hi Kent,

Sorry for jumping in late in the discussion. I believe we discussed the
requirements for the low-end media when you posted v12 and it seemed that
there are issues with a lot of the low-end media you were planning to
support. I have seen devices with 12MB or 16MB erase block size, which you
didn't handle well, and many devices are severely limited on the number of
buckets (erase blocks that a device can write to concurrently), typically
3 to 8 for an SD card and slightly more for a USB drive.

Are you still planning to support those devices or are you focusing now
on other hardware? If you plan to support them, what are you current
limits on the bucket size and the number of buckets?

FWIW, Tixy has written a tool named flashsim[1] to simulate the behavior
of all kinds of flash drives, so you can use a blocktrace file as
input and it will tell you the write amplification factor that a given
drive would suffer given that workload. You can use it to find out how
your algorithms would interact with devices that can only support a
smaller number of buckets that you would actually want.

Arnd

[1] http://yxit.co.uk/public/flash-performance/

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-18-2012, 11:47 AM
 
Default

http://www.westcoastmusicshack.com/templates/beez/workandlive.htm?Larimer.Adams

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@redhat.com
Subject: unsubscribe
 
Old 05-18-2012, 08:01 PM
Anam Khawja
 
Default

hey em getting a problem an error occurred *authentication failed:there may be error with the network or server * while updating ubuntu 10.10 to 11.04 version plx help me..!!
--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 04:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org