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-09-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
* 17 packages missing signoffs
* 1 package 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] (10 total) ==

* i3lock-2.4-2 (i686)
0/2 signoffs
* php-geoip-1.0.8-2 (i686)
0/2 signoffs
* php-memcache-3.0.6-3 (i686)
0/2 signoffs
* php-memcached-2.0.1-4 (i686)
0/2 signoffs
* xdebug-2.2.0RC2-1 (i686)
0/2 signoffs
* i3lock-2.4-2 (x86_64)
0/2 signoffs
* php-geoip-1.0.8-2 (x86_64)
0/2 signoffs
* php-memcache-3.0.6-3 (x86_64)
0/2 signoffs
* php-memcached-2.0.1-4 (x86_64)
0/2 signoffs
* xdebug-2.2.0RC2-1 (x86_64)
0/2 signoffs

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

* vicious-2.0.4-2 (any)
0/2 signoffs
* awesome-3.4.11-4 (i686)
0/2 signoffs
* mariadb-5.5.23-3 (i686)
1/2 signoffs
* virtualbox-modules-lts-4.1.14-1 (i686)
0/2 signoffs
* awesome-3.4.11-4 (x86_64)
0/2 signoffs
* mariadb-5.5.23-3 (x86_64)
1/2 signoffs
* virtualbox-modules-lts-4.1.14-1 (x86_64)
1/2 signoffs


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

* vicious-2.0.4-2 (any), since 2012-04-17


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

1. eric - 5 signoffs
2. foutrelis - 4 signoffs
3. allan - 2 signoffs
4. ibiru - 1 signoffs
5. pierre - 1 signoffs
 
Old 05-09-2012, 06:32 PM
Greg KH
 
Default

On Tue, May 08, 2012 at 02:40:41AM +0100, Steven J Long wrote:
> 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[PS].

Nope, can't make that assurance at all.

Actually, maybe I can make the opposite assurance, let's see what the
future brings...

greg k-h
 
Old 05-09-2012, 06:51 PM
Fabio Erculiani
 
Default

I foresee a new udev fork then.
If udev is going to end up like avahi is, this is *highly* probable.

With "avahi is ..." I actually mean, one single tarball blob depending
on the whole world and its solar system and galaxy.

Please stop throwing lennartware at people. FailAudio has been enough, thanks.
--
Fabio Erculiani
 
Old 05-09-2012, 08:43 PM
David Lehman
 
Default

Patch 1: Don't explicitly download filelists when setting up a repo.
In my limited testing it wasn't needed. Yum will download it on demand
when it is needed.

Patch 5: The problem with using a YumBase instance across multiple
threads is the sqlite used for package sacks does not allow use from
multiple threads, regardless of concurrency. All that's really needed
to allow for access across multiple threads is to unset all of the
YumBase instance's package sacks. This means some slowness the next
time you access something that needs the sacks since it has to rebuild
them. This kind of sucks, but I don't see a better alternative for now.

Patch 6: The loop in checkSoftwareSelection doesn't make sense. The UI
should handle check/adjust/recheck looping.

The rest are fairly self-explanatory.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-09-2012, 09:06 PM
Chris Lumens
 
Default

> The rest are fairly self-explanatory.

#7 is definitely the tricky one of the bunch, but I think I'm following
along with it. Aside from my one other mail, these look good.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-09-2012, 10:36 PM
Greg KH
 
Default

On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
> I foresee a new udev fork then.

Please feel free to do so, the code has been open since the first day I
created it.

Remember, forks are good, there's nothing wrong with them, I strongly
encourage people to do them if they wish to, it benefits everyone
involved.

> If udev is going to end up like avahi is, this is *highly* probable.

That's an odd transition...

> With "avahi is ..." I actually mean, one single tarball blob depending
> on the whole world and its solar system and galaxy.

Hyperbole, how nice

> Please stop throwing lennartware at people. FailAudio has been enough, thanks.

The use of these terms is both rude and totally uncalled for. You
should be ashamed of yourself.

Seriously, that's unacceptable behavior from anyone.

No one forces you to use any of this software if you do not want to.
There are lots of other operating systems out there, feel free to switch
to them if you do not like the way this one is working out, no one is
stopping you. But for you to disparage someone who has given immense
bodies of work to the community, and you, for free, is horrible behavior
and needs to stop right now.

greg k-h
 
Old 05-09-2012, 11:51 PM
Paul Zimmerman
 
Default

Miles Bader <miles@gnu.org> writes:

>It may also be a problem with your service provider -- I had a problem
>(back when I still used PPP) where the connection was getting dropped
>mysteriously, and [after much frustration trying to figure out what
>was happening] it turned out my provider didn't support TCP header
>compression; turning off that feature in PPP made everything work.

>Apparently windows PPP clients didn't use header compression, so they
>didn't consider it an issue ... -miles

Not likely here. This pppd issue is the same problem I had back in 1996 when I was connecting to the local university. But now I am using a local small ISP. Two different providers, same problem. When pppd starts, it tries to negotiate the compression and this is accepted. So it is enabled. A few minutes later the connection simply stops working with an error message "Lost compression sync" in the log. So it is enabled, but the local system cannot keep track of it for some reason. That is either pppd itself or the kernel driver for serial connections. Disable "Van Jacobson" compression ("-novj" on the command line or edit the config file) and the problem goes away. What makes it so annoying is that it's sixteen years old. No one has bothered to fix this in over a decade?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1336607491.48983.YahooMailNeo@web162603.mail.bf1.y ahoo.com">http://lists.debian.org/1336607491.48983.YahooMailNeo@web162603.mail.bf1.y ahoo.com
 
Old 05-10-2012, 01:08 AM
Patrick Lauer
 
Default

On 05/10/12 06:36, Greg KH wrote:
> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>> I foresee a new udev fork then.
> Please feel free to do so, the code has been open since the first day I
> created it.
>
> Remember, forks are good, there's nothing wrong with them, I strongly
> encourage people to do them if they wish to, it benefits everyone
> involved.
Forks are often unnecessary.

Now instead of working on something useful I get to spend my time
reverting to previous behaviour, just so I can have a working solution
instead of a shiny one.

Are we really doing so well that we can just rewrite everything instead
of maybe, for once, have things boring predictable and bugfree? I mean
... things were going so well. Machines Just Booted Every TIme.

And now - UEFI is glitching all over the place, the GPT-aware
bootloaders have config files with insane complexity and are exquisitely
buggy, and someone thought making the init system exciting would just
make life oh so much better. Result: I can't get more than a blinking
cursor out of some machines without resorting to Dirty Hacks I would
really prefer not to even consider.


Seriously. I don't have time for these games. Stop breaking stuff!
>
>> If udev is going to end up like avahi is, this is *highly* probable.
> That's an odd transition...
Same people involved, same mentality - and we don't want to be standing
on the sides saying "Told you so" again. Gets boring.
>
>> With "avahi is ..." I actually mean, one single tarball blob depending
>> on the whole world and its solar system and galaxy.
> Hyperbole, how nice
>
>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> The use of these terms is both rude and totally uncalled for. You
> should be ashamed of yourself.
It's reactive. I've been called stupid, conservative, behind the times,
user of obsolete software that will go the way of the dinosaurs. Why
should we be ashamed of not agreeing with these funny pranksters?
>
> Seriously, that's unacceptable behavior from anyone.
Then make it stop?
>
> No one forces you to use any of this software if you do not want to.
Yeah, I can just stop updating. Sounds like a solution to all problems
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you. But for you to disparage someone who has given immense
> bodies of work to the community, and you, for free, is horrible behavior
> and needs to stop right now.
Goes both ways. We're here because of Freedom, in various flavours.
Freedom to copy things around and use for free. Freedom to swap out one
part and use another.
Freedom to break things badly.

So why would I give up my freedom to tinker just because someone else is
writing more code than I do?
And I still have the freedom to complain all day long about undesigned
stuff people try to force on me.

Hey, you even have the freedom to complain about my complaining.

Either way, I hope I can continue using Free Linux for a while and not
be forced to use random things that are silly. I'd have expected you to
support that.

Take care,

Patrick
 
Old 05-10-2012, 03:07 AM
Kent Overstreet
 
Default

bcache: a cache for arbitrary block devices using an SSD.

Short overview:
Bcache does both writethrough and writeback caching. It presents itself as a
new block device, a bit like say md. You can cache an arbitrary number of
block devices with a single cache device, and attach and detach things at
runtime - it's quite flexible.

It's very fast. It uses a b+ tree for the index, along with a journal to
coalesce index updates, and a bunch of other cool tricks like auxiliary binary
search trees with software floating point keys for searching within btree
nodes.

Bcache is solid, production ready code. There are still bugs being found that
affect specific configurations, but there haven't been any major issues found
in awhile - it's well past time I started working on getting it into mainline.

It's a lot of code - I tried to split it out so that it'd make some sort of
sense for reviewing. Let me know if there's anything else I can do to make
review easier.

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.

Kent Overstreet (16):
Only clone bio vecs that are in use
Bio pool freeing
Revert "rw_semaphore: remove up/down_read_non_owner"
Fix ratelimit macro to compile in c99 mode
Export get_random_int()
Export blk_fill_rwbs()
Closures
bcache: Documentation, and changes to generic code
Bcache: generic utility code
bcache: Superblock/initialization/sysfs code
bcache: Core btree code
bcache: Bset code (lookups within a btree node)
bcache: Journalling
bcache: Request, io and allocation code
bcache: Writeback
bcache: Debug and tracing code

Documentation/ABI/testing/sysfs-block-bcache | 156 ++
Documentation/bcache.txt | 255 +++
block/blk-core.c | 2 +-
drivers/block/Kconfig | 2 +
drivers/block/Makefile | 1 +
drivers/block/bcache/Kconfig | 42 +
drivers/block/bcache/Makefile | 8 +
drivers/block/bcache/alloc.c | 591 +++++++
drivers/block/bcache/bcache.h | 839 ++++++++++
drivers/block/bcache/bset.c | 1149 +++++++++++++
drivers/block/bcache/bset.h | 218 +++
drivers/block/bcache/btree.c | 2249 ++++++++++++++++++++++++++
drivers/block/bcache/btree.h | 272 ++++
drivers/block/bcache/debug.c | 574 +++++++
drivers/block/bcache/debug.h | 53 +
drivers/block/bcache/io.c | 198 +++
drivers/block/bcache/journal.c | 722 +++++++++
drivers/block/bcache/journal.h | 113 ++
drivers/block/bcache/request.c | 1470 +++++++++++++++++
drivers/block/bcache/request.h | 58 +
drivers/block/bcache/stats.c | 243 +++
drivers/block/bcache/stats.h | 58 +
drivers/block/bcache/super.c | 2000 +++++++++++++++++++++++
drivers/block/bcache/sysfs.c | 802 +++++++++
drivers/block/bcache/sysfs.h | 99 ++
drivers/block/bcache/trace.c | 26 +
drivers/block/bcache/util.c | 572 +++++++
drivers/block/bcache/util.h | 657 ++++++++
drivers/block/bcache/writeback.c | 518 ++++++
drivers/block/rbd.c | 2 +-
drivers/char/random.c | 1 +
drivers/md/dm.c | 27 +-
drivers/md/md.c | 3 +-
fs/bio.c | 55 +-
include/linux/bio.h | 7 +-
include/linux/blk_types.h | 2 +
include/linux/cgroup_subsys.h | 6 +
include/linux/closure.h | 614 +++++++
include/linux/ratelimit.h | 2 +-
include/linux/rwsem.h | 10 +
include/linux/sched.h | 4 +
include/trace/events/bcache.h | 257 +++
kernel/fork.c | 4 +
kernel/rwsem.c | 16 +
kernel/trace/blktrace.c | 1 +
lib/Kconfig | 3 +
lib/Kconfig.debug | 9 +
lib/Makefile | 2 +
lib/closure.c | 363 +++++
49 files changed, 15288 insertions(+), 47 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-block-bcache
create mode 100644 Documentation/bcache.txt
create mode 100644 drivers/block/bcache/Kconfig
create mode 100644 drivers/block/bcache/Makefile
create mode 100644 drivers/block/bcache/alloc.c
create mode 100644 drivers/block/bcache/bcache.h
create mode 100644 drivers/block/bcache/bset.c
create mode 100644 drivers/block/bcache/bset.h
create mode 100644 drivers/block/bcache/btree.c
create mode 100644 drivers/block/bcache/btree.h
create mode 100644 drivers/block/bcache/debug.c
create mode 100644 drivers/block/bcache/debug.h
create mode 100644 drivers/block/bcache/io.c
create mode 100644 drivers/block/bcache/journal.c
create mode 100644 drivers/block/bcache/journal.h
create mode 100644 drivers/block/bcache/request.c
create mode 100644 drivers/block/bcache/request.h
create mode 100644 drivers/block/bcache/stats.c
create mode 100644 drivers/block/bcache/stats.h
create mode 100644 drivers/block/bcache/super.c
create mode 100644 drivers/block/bcache/sysfs.c
create mode 100644 drivers/block/bcache/sysfs.h
create mode 100644 drivers/block/bcache/trace.c
create mode 100644 drivers/block/bcache/util.c
create mode 100644 drivers/block/bcache/util.h
create mode 100644 drivers/block/bcache/writeback.c
create mode 100644 include/linux/closure.h
create mode 100644 include/trace/events/bcache.h
create mode 100644 lib/closure.c

--
1.7.9.rc2

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-10-2012, 03:08 AM
Rich Freeman
 
Default

On Wed, May 9, 2012 at 9:08 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 05/10/12 06:36, Greg KH wrote:
>> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
>> The use of these terms is both rude and totally uncalled for. *You
>> should be ashamed of yourself.
> It's reactive. I've been called stupid, conservative, behind the times,
> user of obsolete software that will go the way of the dinosaurs. Why
> should we be ashamed of not agreeing with these funny pranksters?

Look, I have pretty mixed feelings about all the vertical integration.
However, let's at least do each other the professional courtesy of
not resorting to name-calling. We're allowed to disagree, and that's
OK. By all means voice your opinion. However, let's talk about the
issues, and not the people advocating them.

This is just polite behavior. It is also the rules for posting on
this list, especially if you hold a g.o address.

> So why would I give up my freedom to tinker just because someone else is
> writing more code than I do?

I understand your frustration. Really, I do - I often find myself
sharing it. However, in the end people working on FOSS are basically
free to do what they want, and everybody is free to use or support
what they want. I don't like the fact that most people contributing
to Android tend/aspire to be associated with the commercial market for
smartphones, and as a result they tend to embrace pro-developer /
anti-consumer solutions (like not allowing easy blocking of ads, or
randomizing calls to read the IMEI, etc). However, the market is what
it is. The only thing that is really any different today is that
companies are at least releasing the source for the stuff they do - in
the past they'd have just closed it all off so that there wouldn't
even be the option of forking. If I want to I can at least find the
API call to read my IMEI and tamper with it.

I think part of the community frustration is the increasing level of
commercial support around Linux. That has given us much more robust
stuff to play with, but it also has resulted in a loss of control and
change in general atmosphere. In the world of 1999 Linux market share
took a back seat to hackability. In the world of the Canonicals,
market share matters a great deal, and appealing to open source
contributors matters a lot less.

Rich
 

Thread Tools




All times are GMT. The time now is 11:27 AM.

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