date:20090721

Bug#537749: [Pkg-xfce-devel] Bug#537749: xfce4-settings: xfce4 loses keyboard layout settings after restart

2009-07-21 Thread Yves-Alexis Perez

forwarded 537749 http://bugzilla.xfce.org/show_bug.cgi?id=5205
thanks
On mar, 2009-07-21 at 00:36 +0200, Alex Fernandez wrote:
 Hi,
 
 On Mon, Jul 20, 2009 at 11:18 PM, Yves-Alexis Perezcor...@debian.org
 wrote:
  On lun, 2009-07-20 at 19:10 +0200, Alex Fernandez wrote:
  The keyboard on my Asus Eee PC 1000H has Spanish layout. Xfce4 came
  preconfigured to us layout,
 
  No, Xfce autodetects what X is using. See X documentation to manage
 that
  (hint: dpkg-reconfigure console-setup).
 
 I am a bit confused about this, please forgive my deep ignorance about
 X and xfce4 configuration. I assume you mean
   $ dkpg-reconfigure xserver-xorg
 as console-setup is just used for tty's and these are working fine
 with es layout. 

No, things changed recently. X now uses what console-setup uses, through
hal. So first thing is to dpkg-reconfigure console-setup and configure
it correctly. Then check in “pure” xorg (startx /usr/bin/xterm) how is
the layout configured.

 (Anyway I tried it out too.) But no use: after both
 reconfigures the keyboard keeps us layout, and after a reboot
 everything is back to abnormal (i.e. us layout,
 xfce4-keyboard-settings not working). Of course it is not writing out
 an xorg.conf file, but that is a different issue.

Check /var/log/Xorg.0.log (or the startx /usr/bin/xterm) to see what X
is really using. First fix that.
 
 Also, I have not checked use system defaults, so why should xfce4
 care about what X is using?

Because, by default, xfce will autodetect what X uses and use that.
Changing the layout only works during the session.

  I am trying to tell it explicitly to
 ignore any X configuration and use an es layout. Can it be done?

Yes, chose first a keyboard model, then a keyboard layout.

 What am I doing wrong? Or is it some kind of configuration bug?
 
  so I changed it to Spanish es layout. However, after a system
  restart it turns back to us layout, even if es is the only
  configured option.
 
  Yes, it seems the configuration is saved only when you chose a
 *layout*.
  And what you're chosing is a *keymap*. Another way to have it
 remembered
  is to check/uncheck the “use X configuration”.
 
 Now I am really confused. It says es under Layout, empty variant;
 so I don't know why I am choosing a keymap. Even if I have two layouts
 (us and es), switching between the two does not help. Why is it
 saving the configuration after I add or remove a layout, but not when
 I choose one from the list?

It seems there is a bug there. When you're only adding a layout (and not
a keyboard model, or not checking/unchecking the “Use X configuration”),
no config file is written, so nothing is changed in what X uses (see
above for X stuff)

This is already reported, you can follow and comment upstream bug report
at http://bugzilla.xfce.org/show_bug.cgi?id=5205

Cheers,

-- 
Yves-Alexis


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

Bug#537813: meep: FTBFS on kfreebsd-i386 (due to symbols file)

2009-07-21 Thread Petr Salinger


Package: meep
Severity: important
Version: 0.20.3-3
Tags: patch
User: glibc-bsd-de...@lists.alioth.debian.org
Usertags: kfreebsd

Hi,

the current version fails to build on kfreebsd-i386.

It needs updated symbols file, the same as on (linux-)i386.
Just perform

  cp debian/libmeep-mpi2.symbols.i386 debian/libmeep-mpi2.symbols.kfreebsd-i386
  cp debian/libmeep2.symbols.i386 debian/libmeep2.symbols.kfreebsd-i386

Thanks in advance

Petr




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537815: grub: spelling error in debconf template

2009-07-21 Thread Julien BLACHE

Package: grub
Version: 0.97-54
Severity: minor

Hi,

The newest debconf note in grub contains a spelling error, s/untill/until/.

JB.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30.1
Locale: LANG=C, lc_ctype=fr...@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages grub depends on:
ii  grub-legacy   0.97-54GRand Unified Bootloader (Legacy v

grub recommends no packages.

grub suggests no packages.

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537816: openclipart.openoffice.org: remove Openoffice.org (and vice-versa)

2009-07-21 Thread webnie

Package: openclipart.openoffice.org
Version: 0.18+dfsg-8
Severity: normal


If I try to install openclipart-openoffice.org, apt-get remove all
the packages related to openoffice.org (and vice-versa) if I accept
this option and then reinstall all openoffice.org, apt-get remove
openclipart-openoffice.org.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537817: soprano_2.3.0+dfsg.1-1(sparc/experimental): FTBFS: dpkg-gensymbols failure

2009-07-21 Thread Frank Lichtenheld

Package: soprano
Version: 2.3.0+dfsg.1-1
Severity: serious

Hi,

your package failed to build from source.

| Automatic build of soprano_2.3.0+dfsg.1-1 on njoerd by sbuild/sparc 98-farm
| Build started at 20090721-0131
| **
| Checking available source versions...
| Fetching source files...
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Need to get 575kB of source archives.
| Get:1 http://sinclair.farm.ftbfs.de experimental/main soprano 2.3.0+dfsg.1-1 
(dsc) [1790B]
| Get:2 http://sinclair.farm.ftbfs.de experimental/main soprano 2.3.0+dfsg.1-1 
(tar) [549kB]
| Get:3 http://sinclair.farm.ftbfs.de experimental/main soprano 2.3.0+dfsg.1-1 
(diff) [24.2kB]
| Fetched 575kB in 0s (3034kB/s)
| Download complete and in download only mode
| ** Using build dependencies supplied by package:
| Build-Depends: cdbs (= 0.4.51), debhelper (= 7), cmake (= 2.6.2), quilt, 
pkg-kde-tools (= 0.4), dpkg-dev (= 1.15.3), libclucene-dev, libqt4-dev (= 
4.4.0), librdf0-dev, doxygen, graphviz
| Checking for already installed source dependencies...
[...]
| dh_makeshlibs -plibsoprano4  
| dpkg-gensymbols: warning: some symbols disappeared in the symbols file: see 
diff output below
| dpkg-gensymbols: warning: debian/libsoprano4/DEBIAN/symbols doesn't match 
completely debian/libsoprano4.symbols.sparc
| --- dpkg-gensymbols_libsoprano4_sparc
| +++ dpkg-gensymbols74bS8k 2009-07-21 00:01:15.0 +
| @@ -1088,7 +1088,7 @@
|   
_zn7soprano5query31binarydatetimebooleanexpression9setseconderk9qdatet...@base 
2.1.1
|   _zn7soprano5query31binarydatetimebooleanexpressionc1erk9qdatetime...@base 
2.1.1
|   _zn7soprano5query31binarydatetimebooleanexpressionc2erk9qdatetime...@base 
2.1.1
| - (arch=arm armel hppa m68k mips mipsel 
sparc)_zn7soprano5query31binarydatetimebooleanexpressiond...@base 2.1.1
| +#MISSING: 2.3.0+dfsg.1-1# (arch=arm armel hppa m68k mips mipsel 
sparc)_zn7soprano5query31binarydatetimebooleanexpressiond...@base 2.1.1
|   
_zn7soprano5query32binarynumericalbooleanexpression7privatec1epns0_19numericalexpressione...@base
 2.1.1
|   _zn7soprano5query32binarynumericalbooleanexpression7privatec1erk...@base 
2.1.1
|   
_zn7soprano5query32binarynumericalbooleanexpression7privatec2epns0_19numericalexpressione...@base
 2.1.1
| @@ -1099,7 +1099,7 @@
|   
_zn7soprano5query32binarynumericalbooleanexpression9setsecondepns0_19numericalexpressi...@base
 2.1.1
|   
_zn7soprano5query32binarynumericalbooleanexpressionc1epns0_19numericalexpressione...@base
 2.1.1
|   
_zn7soprano5query32binarynumericalbooleanexpressionc2epns0_19numericalexpressione...@base
 2.1.1
| - (arch=arm armel hppa m68k mips mipsel 
sparc)_zn7soprano5query32binarynumericalbooleanexpressiond...@base 2.1.1
| +#MISSING: 2.3.0+dfsg.1-1# (arch=arm armel hppa m68k mips mipsel 
sparc)_zn7soprano5query32binarynumericalbooleanexpressiond...@base 2.1.1
|   _zn7soprano5query3notc1epns0_17booleanexpressi...@base 2.1.1
|   _zn7soprano5query3notc2epns0_17booleanexpressi...@base 2.1.1
|   _zn7soprano5query3notd...@base 2.1.1
| @@ -2104,7 +2104,7 @@
|   _zlsr11qtextstreamrkn7soprano9stateme...@base 2.1.1
|  libsopranoclient.so.1 libsoprano4 #MINVER#
|  * Build-Depends-Package: libsoprano-dev
| - (optional=external)_zn7qstringc...@base 2.1.1
| +#MISSING: 2.3.0+dfsg.1-1# (optional=external)_zn7qstringc...@base 2.1.1
|   
_zn7soprano6client10dbusclient11createmodelerk7qstringrk5qlistins_14backendsettin...@base
 2.1.1
|   _zn7soprano6client10dbusclient11qt_metacallen11qmetaobject4callei...@base 
2.1.1
|   _zn7soprano6client10dbusclient11qt_metacaste...@base 2.1.1
| @@ -2146,20 +2146,20 @@
|   _zn7soprano6client17localsocketclientd...@base 2.1.1
|   _zn7soprano6client17localsocketclientd...@base 2.1.1
|   _zn7soprano6client17localsocketclientd...@base 2.1.1
| - (arch=alpha arm armel hppa m68k mips mipsel 
sparc)_zn7soprano6client19dbusserverinterface11createmodelerk7qstr...@base 2.1.1
| - (optional=useless)_zn7soprano6client19dbusserverinterface9allmodel...@base 
2.1.1
| +#MISSING: 2.3.0+dfsg.1-1# (arch=alpha arm armel hppa m68k mips mipsel 
sparc)_zn7soprano6client19dbusserverinterface11createmodelerk7qstr...@base 2.1.1
| +#MISSING: 2.3.0+dfsg.1-1# 
(optional=useless)_zn7soprano6client19dbusserverinterface9allmodel...@base 2.1.1
|   _zn7soprano6client21dbusstatementiteratorc1erk7qstring...@base 2.1.1
|   _zn7soprano6client21dbusstatementiteratorc2erk7qstring...@base 2.1.1
|   _zn7soprano6client23dbusqueryresultiteratorc1erk7qstring...@base 2.1.1
|   _zn7soprano6client23dbusqueryresultiteratorc2erk7qstring...@base 2.1.1
| - 
(optional=useless)_zn7soprano6client25dbusnodeiteratorinterface7curren...@base 
2.1.1
| - 
(optional=useless)_zn7soprano6client30dbusstatementiteratorinterface7curren...@base
 2.1.1
| - 
(optional=useless)_zn7soprano6client32dbusqueryresultiteratorinterface16currentstatemen...@base
 2.1.1
| - 
(optional=useless

Bug#531341: Debian bug 531341

2009-07-21 Thread Julie


From: Goswin von Brederlow goswin-...@web.de

Nicolas François nicolas.franc...@centraliens.net writes:

On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallg...@austin.rr.com wrote:


I think that you're confusing the requirement that unknown user names
not be logged, because they might be a user's password with the
non-existent requirement that all unknown user names be treated like
root and not prompted for a password.


No, I was not mentioning the case where an user types her password 
instead

of her username.


If you still think you're right, I'd like to see the source for the
requirement.  I've been through a number of formal evaluations as the
vendor lead (IBM) and we never had that requirement under any evaluation
scheme.


I cannot point you to any source of requirements, except mine:
 1. root's password should not be transmitted on insecure lines
= The password should not be prompted if login is on an insecure 
line

   and login thinks the user might be root.
 2. root can mistype her username
= Any invalid user might be a mistyped root


You can run some heuristic:
1) if user exists and is not root then it is probably not mistyped
2) if user is similar to root (like rot) then assume mistyped
3) assume normal user otherwise


What do you do when rot, roto, rott, et alia, exist?  Again, you're 
leaking user name information and leaving the system open to a (slightly 
more limited) User Enumeration attack.  In a real evaluation, which is the 
claimed justification for this behavior, you don't get to slack off on one 
requirement to make up for another.



If root mistypes his user name as kfgerjhfgsdgfvedj I think then we
can blame root itself. Same if root allows a user rot to be created
and then mistypes his name. In the end the user name is clearly
visible. Watch what you type.


The user name in only visible to the user and anyone sniffing the 
connection.  Since the user knows what they've typed, that leaves packet 
sniffers.  Conveniently the problem at hand is one of a legitimate root user 
entering their password and having it sniffed.  This leaves two choices --


1). You prevent the packet sniffer from knowing, with certainty, that they 
have the correct root password, by denying access, regardless of the 
password.


2). You prevent the packet sniffer from having an opportunity to sniff the 
packet by refusing the connection.  While this satisfies Nicholas' 
requirement, it fails on Human Factors because users tend to type their name 
and password in very quick succession.  Which now results in the password 
being in the user name location in the sign on dialog.


In either instance, the layered security of the system protects itself --  
unless the attacker has access to a secure TTY, they can get a million root 
passwords and they will still be denied access.



 3. login should not leak information about the valid usernames on the
system.
= The user should be prompted a password whether the username is 
valid

   or not.


We all know there is a root user already so no information is leaked. :)


Not at all -- there are protection profiles where the privileged user must 
have the ability to change their name.  In those profiles, the name of the 
super-user is considered to be privileged information, and having it be 
public by making it root violates the profile.



I do not think those requirements can be satisfied at the same time.


But near enough.


Well ... I think what's being described is Security Through Obscurity.  I'd 
still like to see a protection profile which requires the described 
behavior.  As it stands, the alternatives all permit a User Enumeration 
attack of some form or another.


-- Julie. 





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#502316: I confirm

2009-07-21 Thread Russell Adams

This is happening to me once or twice a day, specifically dying when
visual bell happens. Mutt triggers it, tab completion in bash triggers
it.

It may be related to a WM, I am running Xmonad.

$ dpkg -l | grep eterm
ii  eterm0.9.5-1
Enlightened Terminal Emulator

$ Eterm --version
Eterm 0.9.5
Copyright (c) 1997-2006, Michael Jennings (m...@eterm.org) 

Build info:
Built on Sat Jul 26 16:55:01 UTC 2008
actions.c 1.29 2006/01/04 09:22:38 mej
buttons.c 1.46 2006/01/04 09:22:38 mej
command.c 1.115 2008/05/14 19:49:22 mej
draw.c 1.18 2006/01/04 09:22:38 mej
e.c 1.30 2006/01/04 09:22:38 mej
events.c 1.68 2008/05/14 21:54:44 mej
font.c 1.48 2006/02/13 19:52:45 mej
grkelot.c 1.8 2005/04/19 01:57:17 mej
main.c 1.14 2006/01/04 09:22:38 mej
menus.c 1.66 2006/02/13 19:52:45 mej
misc.c 1.29 2006/02/13 19:52:45 mej

options.c 1.145 2008/05/14 21:54:45 mej
pixmap.c 1.119 2006/05/17 19:42:39 mej
screen.c 1.90 2008/05/14 22:26:36 mej
scrollbar.c 1.51 2006/02/13 19:52:45 mej
startup.c 1.59 2008/04/16 03:23:27 vapier
system.c 1.24 2006/05/19 20:45:42 mej
term.c 1.112 2008/05/14 21:54:45 mej
timer.c 1.16 2006/01/04 09:22:41 mej
utmp.c 1.22 2006/02/13 19:52:45 mej
windows.c 1.77 2006/10/30 21:12:12 mej

Debugging configuration:  DEBUG=4 +DEBUG_SCREEN +DEBUG_CMD +DEBUG_TTY
+DEBUG_SELECTION +DEBUG_UTMP +DEBUG_OPTIONS +DEBUG_IMLIB +DEBUG_PIXMAP
+DEBUG_EVENTS +DEBUG_X11 +DEBUG_SCROLLBAR +DEBUG_MENU +DEBUG_TTYMODE
+DEBUG_COLORS

Compile-time toggles:  -PROFILE -PROFILE_SCREEN -PROFILE_X_EVENTS
-COUNT_X_EVENTS +OPTIMIZE_HACKS +PIXMAP_SUPPORT +PIXMAP_OFFSET
+BACKGROUND_CYCLING_SUPPORT +USE_EFFECTS -NO_CURSORCOLOR
-NO_BOLDUNDERLINE -NO_BOLDFONT -NO_SECONDARY_SCREEN -FORCE_CLEAR_CHARS
-PREFER_24BIT -OFFIX_DND +BORDER_WIDTH_OPTION -NO_DELETE_KEY
-FORCE_BACKSPACE +FORCE_DELETE +HOTKEY_CTRL -HOTKEY_META -LINUX_KEYS
+KEYSYM_ATTRIBUTE +XIM -UNSHIFTED_SCROLLKEYS -NO_SCROLLBAR_REPORT
+CUTCHAR_OPTION -MOUSE_REPORT_DOUBLECLICK +XTERM_SCROLLBAR
+MOTIF_SCROLLBAR +NEXT_SCROLLBAR +SCROLLBAR_BUTTON_CONTINUAL_SCROLLING
+META8_OPTION -GREEK_SUPPORT +MULTI_CHARSET -ENABLE_DISPLAY_ANSWER
+NO_VT100_ANS +XTERM_COLOR_CHANGE -DEFINE_XTERM_COLOR -NO_MAPALERT
+MAPALERT_OPTION +UTMP_SUPPORT +HAVE_SAVED_UIDS +ALLOW_BACKQUOTE_EXEC
-WARN_OLDER +ESCREEN

Compile-time definitions:
 PATH_ENV=ETERMPATH
 REFRESH_PERIOD=1
 PRINTPIPE=lp
 KS_DELETE=^[[3~
 SAVELINES=256
 CUTCHARS='()*,;=?...@[\]^`{|} ^I
 MULTICLICK_TIME=500
 SCROLLBAR_DEFAULT_TYPE=1
 SB_WIDTH=10
 SCROLLBAR_INITIAL_DELAY=40
 SCROLLBAR_CONTINUOUS_DELAY=2
 ESCZ_ANSWER=^[[?1;2C
 PTY_GRP_NAME=tty
 
CONFIG_SEARCH_PATH=~/.Eterm/themes:~/.Eterm:/etc/Eterm/themes:/etc/Eterm/themes:/usr/share/Eterm/themes:/etc/Eterm:/etc/Eterm:/usr/share/Eterm
 THEME_CFG=theme.cfg
 USER_CFG=user.cfg


 --
   __
  (..)   Russell Adams / Demosthenes   d...@demosthenes.org
  /\/\
 //  \\Linux Powered since 1996
 ( __ )  PGP Key Id: 0xADA00D29
  ^  ^   Fingerprint:E928 A47A E032 D745 753B  B8AD 36B1 68E1 ADA0 0D29

 --


signature.asc
Description: Digital signature

Bug#537749: [Pkg-xfce-devel] Bug#537749: xfce4-settings: xfce4 loses keyboard layout settings after restart

2009-07-21 Thread Alex Fernandez

Hi,

On Tue, Jul 21, 2009 at 7:52 AM, Yves-Alexis Perezcor...@debian.org wrote:
 No, things changed recently. X now uses what console-setup uses, through
 hal. So first thing is to dpkg-reconfigure console-setup and configure
 it correctly. Then check in “pure” xorg (startx /usr/bin/xterm) how is
 the layout configured.

Sure enough, it autodetects the us layout:

r...@eee: /etc # cat /var/log/Xorg.0.log | grep Layout
(==) No Layout section.  Using the first Screen section.
(==) Assigned the driver to the xf86ConfigLayout
(**) Option XkbLayout us
(**) default keyboard: XkbLayout: us

Even after a console-setup reconfigure, and without an
/etc/X11/xorg.conf file. So it doesn't work. Meanwhile tty's work fine
and use es layout.

 Also, I have not checked use system defaults, so why should xfce4
 care about what X is using?

 Because, by default, xfce will autodetect what X uses and use that.
 Changing the layout only works during the session.

So the layout is stored, but not applied for the next session?
Strange. Wouldn't it make more sense to reapply the keyboard settings
for the next session, if use system defaults is not set?

 It seems there is a bug there. When you're only adding a layout (and not
 a keyboard model, or not checking/unchecking the “Use X configuration”),
 no config file is written, so nothing is changed in what X uses (see
 above for X stuff)

 This is already reported, you can follow and comment upstream bug report
 at http://bugzilla.xfce.org/show_bug.cgi?id=5205

OK. So, to clarify things, there are three different issues here:
  - X server does not pick up the console keyboard settings configured
with console-setup.
  - xfce4 does not set its own keyboard layout, even when told to
ignore system defaults.
  - xfce4 does not change its settings when selecting a keyboard
layout (but it does when picking a different model or changing use
system defaults.

Last to first: the third one is already reported upstream. For the
second one I am waiting to hear your opinion, and then maybe report it
upstream. So only the first one remains. If you agree with the
analysis above, can you reassign this Debian bug to the proper X
package (xserver-xorg maybe) to try and solve the first issue?

Thanks,

Alex.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537732: Info received (Bug#537732: libgl1-mesa-dri: screen goes black when running glxgears)

2009-07-21 Thread Arthur Marsh

After applying the patch at: 
http://bugs.freedesktop.org/attachment.cgi?id=25726

referenced from http://bugs.freedesktop.org/show_bug.cgi?id=21653
and rebuilding mesa and installing it, the problem has gone away.

Regards,

Arthur.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#537764: mirror submission for debian.linux.edu.lv

2009-07-21 Thread Leo Trukšāns

Hello!

Comments inline.

Simon Paillard wrote:

tags 537764 +moreinfo
thanks

Hello Leo,

Thanks for your Debian mirror submission.

Here are a few questions/remarks before we can add your mirror to the
list.

On Mon, Jul 20, 2009 at 07:04:29PM +, Leo Truksans wrote:

Package: mirrors
Severity: wishlist

Submission-Type: new
Site: debian.linux.edu.lv

Thanks for using ftpsync.
Please set MIRRORNAME to debian.linux.edu.lv in the ftpsync
configuration file.

Right. Done.

Type: leaf
Archive-architecture: ALL alpha amd64 arm armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc s390 sparc
Archive-ftp: /pub/debian/

Could you please make a symlink so that the archive is available under
/debian/ ?
Having the same path whatever is the mirror is better.

Done.

Archive-http: /debian/
Archive-rsync: debian/
IPv6: no
Archive-upstream: ftp.pl.debian.org
Updates: twice

You may/should setup push with ftp.pl.d.o, which is the optimal method
to get updates: http://debian.org/mirror/push_mirroring
You can contact them at ftpadmin THE SIGN YOU CAN GUESS task.gda.pl

Well, I chose ftp.pl.debian.org because they had the best ping time
among several close primary mirrors I tried. Here is a question. Is
there a typical source for synchronizing main mirrors in EU countries?
Perhaps a ftp-master.eu.debian.org or something? We intend to become
ftp.lv.debian.org if it's possible.

Maintainer: Leo Truksans l...@linux.edu.lv
Country: LV Latvia
Location: Riga, Latvia

Could you please tell us how much bandwidth is available (or even
peering info)?

Yes, of course. The system is a virtual machine in a cluster which has a
total Internet connection of 3,5Gbps: 1Gbps to Latvian core ISPs and
2,5Gbps to the rest of the world through GEANT network. It's switched
through a 10Gbps line. The physical machines have 1Gbps, though. So, the
short answer is: 1Gbps. It can be scaled, the storage can perform more.

--
Leo Trukšāns
Latvijas Universitāte, Datorikas fakultāte, Linux Centrs
http://www.lu.lv, http://www.lu.lv/dn, http://linux.edu.lv
http://atveries.lv, http://ubuntu.lv, http://ubuntuguide.org

1 2 3 4 5 >

1 - 100 of 404 matches

Mail list logo