Re: including both GL/gl.h and cogl/cogl.h fails on armel and armhf
On 31 December 2011 02:14, Josselin Mouette wrote: > It is cogl which is at fault. Being built against GLES breaks basically > everything that depends on it. armel/armhf only support GLES in hardware so it does make sense to enable it for those platforms. We should try and fix that support where broken, not disable it. >> The cause appears to be cogl being built against GLES2 on arm* while >> it's built against the regular GL on everything else. Am I correct in >> thinking this is done to better support embeeded GPUs? > > Yes, but so far it only works with proprietary drivers. Exactly, and until that changes we have to at least make sure that the available GLES proprietary drivers support the platform. Eg, clutter+cogl works almost 100% on our iMX515 GLES drivers, which we depend on to make Gnome3 hw acceleration working. >> Would the correct course of action be to try and patch toonloop to also >> use GLES2 on armel and armhf? > > No, the best course of action is to revert the change that broke cogl on > arm. Rico, can you revert your related commits? Please do not suggest such things, Until a new armel/armhf system is released that actually supports proper GL in hardware(the iMX6 is supposed to do that, next year), suggesting reverting to GL instead of GLES is totally wrong. So, yes, the proper fix is to try and patch toonloop to use GLES2 on armel/armhf. Otherwise, we might as well not build the packages for arm* at all, as software GL on those platforms is a joke. Regards Konstantinos PS. Speaking with both armhf maintainer hat on and representing an ARM product vendor, and we definitely want GLES working, GL is just out of the question. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabsevwvvyhfbdo2zuxoloersjerqmtvdfx6+q5u+uqjcx-b...@mail.gmail.com
Re: including both GL/gl.h and cogl/cogl.h fails on armel and armhf
On 31 December 2011 11:50, Josselin Mouette wrote: > I object, on principle, to spend time doing specific changes to our > packages for a platform for which only exist proprietary drivers. We > have better things to do than serving as a supermarket on which to base > proprietary operating systems. Some reasons why your objection is irrelevant: 1. Crippling a platform won't help support it. 2. Binary drivers exist because the ARM ecosystem has been such that it never needed -until now- free drivers. Things are moving in the right direction but it will take time -still less time than it took x86 to have working 3d drivers. 3. Even if free drivers are released/reverse-engineered they would *still* be GLES drivers and NOT GL, so changes like that to toonloop would still have to be made. 4. May I remind you that for many years x86 did not have *any* free 3d drivers, but still packages were built with GL support. In anycase, it's only a case of consistency, clutter is already built with GLES-only support for armel/armhf. > It looks to me that these entire platforms are a joke. I have no time for silly arguments, sorry, keep such comments to yourself. > Is there existing, real hardware on which the Debian armel/armhf ports > can work out of the box? With a stock kernel? And no additional drivers > outside of Debian for basic functionality? We're working on that for the past year, for some platforms support is already there in mainline (omap4), and we're working on imx5 stuff. Dunno about the rest. In fact, I'm personally working in getting a working efika kernel image, based on 3.2 mainline + minimal patching to get d-i working and able to install armhf there. As usual display is the source of problems, but for such funcionality I only care for 2D working. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabsevwshw1o126+bpzhuetquo_nhe6gymprpc7krtsk2vi4...@mail.gmail.com
Re: Bug#230832: xserver-xfree86: XkbVariant was fi, kb not working in X
On Κυρ 19 Δεκ 2004 11:23, Christian Perrier wrote: > > The problem is that XkbVariant was set instead of XkbLayout. > > Well read, Denis. According to what I read in localization-config > (l-c) files, it is not supposed to set XkbVariant for Finnish and > certainly not to "fi". > > So, this may finally be a nasty bug in l-c (setting XkbVariant > additionnaly to XkbLayoutwhich indeed means preseeding > xserver-xfree86/config/inputdevice/keyboard/variant) ? ? ?or some > other unrealted thing. > > Konstantinos, some check is needed maybe. l-c does set the XkbVariant but only for the locales that support it, and fi_FI does not support it as I just checked now. I just tried l-c with fi_FI and [EMAIL PROTECTED] (the only locales in there) and XkbVariant does not get configured. Btw, if the locale is not there (say, if the user chosen us_FI) then l-c would do nothing and the user would be on his own to enter the values. Which I think is what happened. I can't reproduce this bug. Franz, btw, I don't see this bug as reassigned to l-c. Konstantinos
Bug#230832: xserver-xfree86: XkbVariant was fi, kb not working in X
On Κυρ 19 Δεκ 2004 12:13, Sven Luther wrote: > Well, i think the main problem would be : 1) to higher the priority > of keymap question in X, and 2) make localization-config only > provide the default, but not mark the question as seen or > something. hm, i don't set the question as seen, which i think is done by the addition of Flags: seen in the debconf entry, which i don't do. Just making the priority higher should work, imho. Konstantinos
Re: Bug#230832: xserver-xfree86: XkbVariant was fi, kb not working in X
On Κυρ 19 Δεκ 2004 12:42, Sven Luther wrote: > On Sun, Dec 19, 2004 at 12:32:29PM +0200, Konstantinos Margaritis wrote: > > On ?? 19 ?? 2004 12:13, Sven Luther wrote: > > > Well, i think the main problem would be : 1) to higher the > > > priority of keymap question in X, and 2) make > > > localization-config only provide the default, but not mark the > > > question as seen or something. > > > > hm, i don't set the question as seen, which i think is done by > > the addition of > > > > Flags: seen > > > > in the debconf entry, which i don't do. Just making the priority > > higher should work, imho. > > So, this is something the X package need to solve ? No, i was wrong it seems. I use debconf-set-selections, which marks each question as 'seen' by default. I don't see some way to override this setting in debconf-set-selections, so perhaps we could ask Joey to add support for not setting the seen flag by default. Konstantinos
Re: Bug#230832: xserver-xfree86: XkbVariant was fi, kb not working in X
reassign 230832 debconf
tags 230832 + patch
thanks
On Κυρ 19 Δεκ 2004 13:09, Sven Luther wrote:
> A -u --unseen flag would be welcome indeed.
Done. Please include the patch attached to debconf-set-selections.
This will allow the extra flag to be used in l-c. It seems to work for
me...
Konstantinos
--- debconf-set-selections.orig 2004-12-19 13:16:01.0 +0200
+++ debconf-set-selections 2004-12-19 13:38:22.0 +0200
@@ -5,6 +5,7 @@
Usage: debconf-set-selections [-vc] [file]
-v, --verbose verbose output
-c, --checkonly only check the input file format
+ -u, --unseed do not set the 'seen' flag
EOF
exit(1);
}
@@ -13,7 +14,7 @@
use Debconf::Db;
use Debconf::Template;
use Getopt::Long;
-use vars qw(%opts $filename $debug $error $checkonly);
+use vars qw(%opts $filename $debug $error $checkonly $unseen);
sub info {
my $msg = shift;
print STDERR "info: $msg\n" if $debug;
@@ -45,7 +46,9 @@
}
$question->addowner($owner, $type);
$question->value($content);
- $question->flag("seen", "true");
+ if (! $unseen) {
+ $question->flag("seen", "true");
+ }
}
my @knowntypes = qw(select boolean string multiselect note password text title);
sub ok_format {
@@ -61,6 +64,7 @@
GetOptions(
"verbose|v" => \$debug,
"checkonly|c" => \$checkonly,
+ "unseen|u" => \$unseen,
) || usage();
Debconf::Db->load;
$error = 0;
Re: Bug#230832: xserver-xfree86: XkbVariant was fi, kb not working in X
On Κυρ 19 Δεκ 2004 12:29, Konstantinos Margaritis wrote: > l-c does set the XkbVariant but only for the locales that support > it, and fi_FI does not support it as I just checked now. I just > tried l-c with fi_FI and [EMAIL PROTECTED] (the only locales in there) and > XkbVariant does not get configured. Btw, if the locale is not there > (say, if the user chosen us_FI) then l-c would do nothing and the > user would be on his own to enter the values. Which I think is what > happened. > > I can't reproduce this bug. Tapio, regarding the XkbVariant misconfiguration, could you re-do the installation steps and please give us the following info right before you run aptitude to install everything: * values of the following debconf entries in the /var/cache/debconf/config.dat: xserver-xfree86/config/inputdevice/keyboard/layout xserver-xfree86/config/inputdevice/keyboard/options xserver-xfree86/config/inputdevice/keyboard/model xserver-xfree86/config/inputdevice/keyboard/variant these are the only ones that l-c tampers with. * version of l-c used * locale used (at the moment only fi_FI, and [EMAIL PROTECTED] are supported by l-c). If it's a bug in l-c itself i'd like to fix it of course, if not, i think we'd all like to know where it came from. Konstantinos
Re: Pre-seeding XFree settings for keyboard in Debian Installer
On Κυρ 27 Ιουν 2004 09:21, Christian Perrier wrote: > Quoting Petter Reinholdtsen ([EMAIL PROTECTED]): > > [Christian Perrier] > > > > > As a way to circumvent this, I propose that we pre-seed > > > xserver-xfree86 settings about keyboard, mostly > > > "xserver-xfree86/config/inputdevice/keyboard/model" and > > > "xserver-xfree86/config/inputdevice/keyboard/layout" with > > > appropriate values, depending on the chosen keyboard layout > > > during the kbd-chooser step in d-i. > > > > Konstantinos Margaritis is working on packaging the debian-edu > > tool to do this. It is currently called > > locale-config-skolelinux, but will probably be renamed before it > > is uploaded. > > > > The package is available from > > ftp://ftp.skolelinux.no/skolelinux/dists/woody/local/binary- > >i386/non-official/>. > > Ah, this is fine, then. Konstantinos can you give details about > this? Ok, I started tidying up the package, basically it doesn't really need much tidying up (Petter has done a good job :-), but here are my comments: * package has been renamed to localization-config as discussed with Petter in debconf. * of all the conffiles.d, we only need xfree86-kbd, and probably kde(but updated for kde 3) * ispell needs to be updated to new versions which are (I think) debconf base * maybe add gnome configurations (but I have very little gnome experience) * we don't really need locale and timezone (as these are handled by debian-installer) * we also don't need to configure links and ktouch (as these are optional packages and not debconf based), ltsp-xfree86-kbd (as it's skolelinux specific) and opera6 (not available in debian itself) * If we decide to update kde as well, then we have to either: a) make kde configurable by debconf, or b) split the package into 2 subpackages, one to be called before X configuration (thus pre-seeding debconf values) and one after (finishing up KDE configuration). I don't really like any of these solutions, but I would go for one I'd go for the first. As it is, KDE 3 does quite a good job of detecting the default locale after a first installation (there is only a problem with the default X dpi and fonts resolution), but I only tested this for Greek. So, perhaps we could just skip KDE configuring as well. So that leaves us with just XFree86 and (possibly) ispell preseeding. Thoughts? Konstantinos
Re: Pre-seeding XFree settings for keyboard in Debian Installer
On Τρι 29 Ιουν 2004 14:12, Petter Reinholdtsen wrote: > [Konstantinos Margaritis] > > > * of all the conffiles.d, we only need xfree86-kbd, and probably > > kde(but updated for kde 3) > > If possible, make sure the package work in Woody as well as in > Sarge/Sid. ok, how about spliting the conffiles to two dirs, for woody/sarge, or with a suffix in the filename (eg. kde2.woody, kde3.sarge). > > * ispell needs to be updated to new versions which are (I think) > > debconf base > > Yes, some major rewrites have been done to the ispell config. > Perhaps ispell should be replaced by aspell, which I'm told is a > better spell checker? I'm all for aspell as it is better maintained upstream and has actuall support for non-latin languages (eg. greek) > Is the timezone really working as it should in d-i? Good. for me at least yes but the timezone setup is quite simple for Greece, with only one option, I don't know if it works as it should with more complex locale configs(eg. US, China, etc). > > Well, _need_ is a strange criteria to use. As long as they only > fix the config when the package is installed, I would very much > like to handle as many packages as possible. ok, but these should go after installation of the packages is finished. > You don't need to split the package in two. You can have one > package, with two base-config fragments. > > I do not think it will be possible to get all packages configurable > with debconf in a reasonable time frame, so I believe we need to > keep both ways of configuration. Ok, basically i'm creating a list of configuration to be executed before installation of packages, and another one at the end of the installation. (in reality, there will be 2 such pairs, one for woody and one for sarge). Will keep you posted. Konstantinos
Re: Pre-seeding XFree settings for keyboard in Debian Installer
On Τρι 29 Ιουν 2004 17:34, Konstantinos Margaritis wrote:
> ok, how about spliting the conffiles to two dirs, for woody/sarge,
> or with a suffix in the filename (eg. kde2.woody, kde3.sarge).
Ok, here is what i have now:
conffiles.d/:
sarge woody
conffiles.d/sarge:
ispell.preinst xfree86-kbd.preinst
conffiles.d/woody:
ispell.postinst ktouch.postinst locale.preinstopera6.postinst
xfree86-kbd.preinst kde2.postinstlinks.postinst
ltsp-xfree86-kbd.? timezone.postinst
I have also updated the update-locale-config script to take one more
parameter {preinst/postinst} so that it can be called in two separate
times, one at the start (runnint the preinst scripts) and one at the
end running the postinst scripts.
It will read the /etc/debian_version and accordingly run the
appropriate scripts from the correct directory.
> > Yes, some major rewrites have been done to the ispell config.
> > Perhaps ispell should be replaced by aspell, which I'm told is a
> > better spell checker?
In the meantime, since the current ispell configuration is
debconf-based, I will make one extra script for sarge ispell.preinst.
Also, now that I think about it, there is a new infrastructure for
dictionaries, dictionaries-common that configures the appropriate
ispell dictionary from a list. So perhaps I should just pre-seed
dictionaries-common instead?
Konstantinos
Re: Pre-seeding XFree settings for keyboard in Debian Installer
On Τετ 30 Ιουν 2004 00:39, Petter Reinholdtsen wrote:
> Not sure if it is a good idea to hardcode in the names of debian
> releases like that. The package should work also after sarge is
> released, and a new version is being developed.
There is no reason why it should not work, after all, I can just add a
new option for the next release. Right now, I keep a map with
possible values in debian_version and corresponding script folders,
like that:
my %supported_versions = ( 'woody' => { FOLDER => 'woody' },
'sarge' => { FOLDER => 'sarge' },
'testing/unstable' => { FOLDER => 'sarge' }
);
if in the future we have another release, we could just add one more
entry. Of course if it's a matter of the folder names, sure I could
change these.
> > It will read the /etc/debian_version and accordingly run the
> > appropriate scripts from the correct directory.
>
> This do not work. We tried collecting that info in
> popularity-contest, and it is often changed in unpredictable ways.
> We have been unable to find a sure way to detect which
> version/codename of debian is installed.
unpredictable ways? I don't really understand what you mean. It *is*
there for a reason, if it is not actually usable, then we might just
as well, drop it! :-)
> > In the meantime, since the current ispell configuration is
> > debconf-based, I will make one extra script for sarge
> > ispell.preinst.
>
> Sounds good to get this written. :)
Yup, too bad that aspell has no such support... I'll tell you when I
have something to test...
> > Also, now that I think about it, there is a new infrastructure
> > for dictionaries, dictionaries-common that configures the
> > appropriate ispell dictionary from a list. So perhaps I should
> > just pre-seed dictionaries-common instead?
>
> I do not know how this work.
Well, from what little I've seen, it appears that dictionaries-common
is supposed to configure ispell itself. So if we pre-seed
dictionaries-common... :-)
Konstantinos
Re: Pre-seeding XFree settings for keyboard in Debian Installer
On Τετ 30 Ιουν 2004 01:39, Petter Reinholdtsen wrote: > Well, sure, you can keep adding new options all the time, but it > will be a maintenence problem keeping it correct and up to date. True, but this applies for everything, and maintaining will be easy for older releases, only the latest will actually need active maintenance... Anyway, I attach the update-locale-config script as I've changed it so far. I am no perl expert, so if you find anything that needs tidying up, feel free to correct it. I haven't uploaded anything to the skolelinux cvs, and I think that would be a bad idea anyway, I don't want to break anything in skolelinux right now. FWIW, it seems to work now (I commented out the system() line for initial testing). > The content in that file is free text, and collecting it in popcon > showed 10-15 different values. Most of them would be hard to map > to the proper script. We gave up collecting and using the > information after seeing how different the values actually were. > > Yes, we might just as well dropp it. Could you please send me these values? Konstantinos update-locale-config Description: Perl program
Re: Pre-seeding XFree settings for keyboard in Debian Installer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I have now finished the infrastructure using version maps, but
before I upload I would like to describe the process, for feedback,
comments etc.
Basically the dir structure is this:
/conffiles.d:
sarge/ woody/ xfree86-kbd.preinst ispell.preinst ispell.postinst
ktouch.postinst kde2.postinst links.postinst
./conffiles.d/sarge:
xfree86-kbd
./conffiles.d/woody:
ispell ktouch xfree86-kbd kde2 links
You might notice that ispell has both preinst and postinst scripts,
this is because skolelinux/woody uses postinstallation configuration,
while ispell in sarge, can be preconfigured using debconf preseeding.
And the process:
update-locale-config is called, if a flag -p is given, then it
executes the .preinst scripts in conffiles.d, otherwise it executes
the .postinst scripts in the same folder. This is to ensure that we
can use configuration in pre- and post- stages of installation.
Each *.{pre,post}inst script has a version map that it uses to decide
which version it should run. I have separated the common routines in
common.pl, and use this to get the appropriate version. Here is a
small part of the conffiles.d/xfree86-kbd.preinst:
-
require 'common.pl';
getopts("dlp", \%opts);
init();
my %xvermap = ( '4.1.0-1', => { RELEASE => 'woody' },
'4.3.0-1', => { RELEASE => 'sarge' }
);
my $script = "xfree86-kbd";
my $package = "xserver-xfree86";
my $release = get_release($package, %xvermap);
$script = "$release/".$script;
print "Running $script $lang\n";
system ($script, $lang) if -x $script;
- --
Basically, I wanted it small and clean, so that it would be easy to
create new ones. The xvermap array holds the versions and release
names. I just put the minimum versions in which the configuration is
different (4.3.0 introduced some slight differences in XkbOptions).
I then execute the $release/$script file, which is the same script as
it was in locale-config-skolelinux. I prefered this approach as I
really like modularity and dislike huge scripts with lots of if
clauses :-)
If for some reason, an older/newer version has no available method for
{pre,post}-configuration then the script can just be a dummy script
(a link to /bin/true perhaps?).
How does get_release() then works?
If the package exists AND is installed then i compare the currently
installed version to the version map. If it is not installed then I
check -using apt availability list- againsg the latest version.
If the package does not exist or something went wrong with other
methods, I fallback to checking /etc/debian_version (though that
should not happen often).
That's about it, I will have uploaded the package later this day at
http://people.debian.org/~markos/debian/
Feel free to comment.
Konstantinos
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA8BuZIU9oQVFfm3QRAghEAJwNB2rPr+5NSpZaOoP4OsH7ktacLwCdFAq9
pYF3meY2qbA0KHIFSeKHycU=
=lRzG
-END PGP SIGNATURE-
Bug#251509: file:/home/markos/pics/Conferences[INTL:el] Please include updated Greek debconf translation
Package: xfree86 Severity: wishlist Tags: patch l10n Attached. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.25 Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 el.po.gz Description: Binary data
Re: Pre-seeding XFree settings for keyboard in Debian Installer
On Κυρ 27 Ιουν 2004 09:21, Christian Perrier wrote: > Quoting Petter Reinholdtsen ([EMAIL PROTECTED]): > > [Christian Perrier] > > > > > As a way to circumvent this, I propose that we pre-seed > > > xserver-xfree86 settings about keyboard, mostly > > > "xserver-xfree86/config/inputdevice/keyboard/model" and > > > "xserver-xfree86/config/inputdevice/keyboard/layout" with > > > appropriate values, depending on the chosen keyboard layout > > > during the kbd-chooser step in d-i. > > > > Konstantinos Margaritis is working on packaging the debian-edu > > tool to do this. It is currently called > > locale-config-skolelinux, but will probably be renamed before it > > is uploaded. > > > > The package is available from > > ftp://ftp.skolelinux.no/skolelinux/dists/woody/local/binary- > >i386/non-official/>. > > Ah, this is fine, then. Konstantinos can you give details about > this? Yes, sure. Sorry for being so quiet these days, I'm relocating to another city and things are terribly busy nowadays! Well, I can only say that I need to clean it up (not that it is not clean, but perhaps add a few more options, etc) and I'll probably upload it during the coming week (since I've finished all my projects and all my teaching :-) I'll keep you posted about it, and please accept my apologies for this delay. Konstantinos
Re: Keyboard preseed for X
(Cc'ing -i18n and -x for completeness) On ÎÎÏÎÏÎÎÏÎ 07 ÏÎÏÎÎÏ 2005 08:33, Christian Perrier wrote: > > So I was thinking about hacking on localization-config so that it > > will use the debconf key obtained during installation to set up > > the keyboard and map that one to the keyboard setup for X > > instead. The debconf question is answered like this on my new > > install: > > Kostas (Konstantinos Margaritis, l-c maintainer) plans to do > exactly this. As Otavio mentioned, look at these days discussions > in the archive. Ok, I have finished working on this and am now in the process of testing & packaging. The main changes now are these: 1) It tries to read the debconf variable debian-installer/keymap. If it finds it, it uses this map[1] to preseed the XFree86 keyboard with the correct values. All these values have been collected by asking the correct people and trying to use common sense when I had no choice. In no case have I changed these values, so if there is something wrong, don't blame me. If you _do_ see a missing/faulty entry, please drop me a mail. 2) If debian-installer/keymap is not set or if its value is not in the map, the script will try to fall back to the previous method of checking the locale but with a difference. This time, it will try to be intelligent and if a locale entry is not in the list, the script will try to guess it (where that is possible). I give you an example using a quite improbable combination for a locale: [EMAIL PROTECTED] Yes, it's quite unlikely anyone will choose this, but I just want to prove the point. If it doesn't find (which it won't) this locale in the list, the script will try to guess the correct settings to use, trying to strip the locale progressively. Here is the output: [EMAIL PROTECTED] not defined! removing part after @ (if any)... lng = fi_ES.UTF-8 fi_ES.UTF-8 not defined! removing encoding (if any)... lng = fi_ES fi_ES not defined! removing country part (if any)... lng = fi fi not defined! last chance, will take the first entry from a search in the list... [EMAIL PROTECTED] lng = [EMAIL PROTECTED] Found [EMAIL PROTECTED] =>Finnish (FI) If the list contains more than one entries then it will pick the first one (alphabetically for now) but I'm thinking of a priority queue if there is a need in the future). So far the script seems to be working quite fine, but as it's quite a rewrite, I'd appreciate some testing before it gets included in d-i. I will do the upload later today (localization-config v 0.110), after i write up some comments, update the changelog, etc. Konstantinos --- [1] This is the map produced dynamically by the command: /usr/lib/localization-config/sarge/xfree86-kbd showkeymaps and is uploaded at http://people.debian.org/~markos/console_x_map.txt feel free to check your settings. pgpmuzfigasie.pgp Description: PGP signature
Re: Keyboard preseed for X
(sorry for the cross-post, feel free to keep only -i18n) On ÎÏÎÏÎ 18 ÏÎÏÎÎÏ 2005 00:06, Konstantinos Margaritis wrote: > So far the script seems to be working quite fine, but as it's quite > a rewrite, I'd appreciate some testing before it gets included in > d-i. I will do the upload later today (localization-config v > 0.110), after i write up some comments, update the changelog, etc. Finished at last, but I would like some testing first before I upload to unstable. You can find it at: http://people.debian.org/~markos/localization-config/ Konstantinos pgp9eZkaZ9ra9.pgp Description: PGP signature
Bug#227616: Please add Greek debconf translation (attached)
Package: xserver-xfree86 Version: 4.2.1-12.1 Severity: wishlist Tags: patch Please find attached the Greek version of the debconf message file. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux silmaril 2.4.22 #1 Thu Nov 6 18:21:15 EET 2003 i686 Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 Versions of packages xserver-xfree86 depends on: ii debconf 1.3.22 Debian configuration management sy ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii xserver-common 4.2.1-12.1 files and utilities common to all ii zlib1g 1:1.2.1-3compression library - runtime xfree86-greek.tgz Description: Binary data
Bug#227616: Please add Greek debconf translation (attached)
On Wednesday 14 January 2004 20:41, Branden Robinson wrote: > Thank you! I have committed this file to the Subversion > repository. > > You should be aware that the templates have changed a little bit > since 4.2.1-12.1. > > I am attaching the el.po file as changed by debconf-updatepo. > There aren't too many changes: two msgids have become fuzzy, and > another has been dropped entirely. Here they are: Hi, Here is the po file, updated and with a few typos fixed. Thanks! Konstantinos el.po Description: application/gettext
Bug#227616: Update for the translations
Hi Branden, Please consider these instead they contain spelling corrections. Konstantinos xfree86-greek.tgz Description: application/tgz
Bug#227616: Update for the translations
On Monday 26 January 2004 20:56, Branden Robinson wrote: > The el.po file that I just checked into SVN is MIME-attached. If > you have a chance to rectify the fuzz, please mail me back just the > el.po file, not a tar archive. Hi Branden, yes sorry for that one, there seemed to be a problem with one of the po's that I sent and i decided to tar.gz the lot of them. :-) Anyway here it is! Konstantinos el.po Description: application/gettext
Re: Merge X keyboard settings from localization-config to xserver-xorg?
(CCing to the debian-x and debian-boot lists) On Κυριακή 23 Οκτώβριος 2005 10:31, Miroslav Kure wrote: > Hi, > > I've noticed (#333960), that xserver-xorg now attempts to setup > X keyboard in its config script based on keyboard layout selected > in d-i. > > Maybe it is time to merge the settings from localization-config to > xserver-xorg to have just one place to take care of? FWIW, Iäm about to upload a new version of l-c that preseeds xserver-xorg debconf keys, with the same values. With regard to #333960, I haven't looked at what the script does, but maybe it's a good idea to move the configuration data from localization-config in the package itself, as l-c has a fairly broad and consistent database of locale/consolekb/Xkb configurations. It also has fallback modes, first it tries to setup the Xkb config using the debian-installer/keymap debconf value. If that is unset or if it fails, it uses locale configuration, well, if that fails as well, there's sth wrong with the installation :-) Anyway, I'd be happy to help migrate this logic into the X.org config scripts. Konstantinos
Bug#344590: [INTL:el] Greek language update
Package: xserver-xorg Version: 6.8.2.dfsg.1-11 Severity: minor Tags: patch l10n Please include Greek language update (done by Kostas Papadimas) Konstantinos -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Versions of packages xserver-xorg depends on: ii debconf [debconf-2.0]1.4.62 Debian configuration management sy ii libc62.3.5-8 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library ii libxau6 6.8.2.dfsg.1-11 X Authentication library ii libxdmcp66.8.2.dfsg.1-11 X Display Manager Control Protocol ii xserver-common 6.8.2.dfsg.1-11 files and utilities common to all ii zlib1g 1:1.2.3-8 compression library - runtime Versions of packages xserver-xorg recommends: ii discover11.7.17 hardware identification system ii laptop-detect0.12.1 attempt to detect a laptop ii mdetect 0.5.2.1 mouse device autodetection tool ii xlibs6.8.2.dfsg.1-11 X Window System client libraries m pn xresprobe (no description available) -- debconf information excluded xserver-xorg_debian_po_el.po.gz Description: Binary data
Bug#604672: xserver-xorg-input-synaptics: Please add armhf support
Source: xserver-xorg-input-synaptics
Severity: wishlist
Tags: patch
Hi,
The armhf port has reached a very good state (at 87%) at debian-ports.org,
and I'm now mass-filing bug reports to packages for armhf support.
Most packages just have to add armhf in the architecture field. The complete
list is in http://wiki.debian.org/ArmHardFloatTodo
The package builds fine using the attached patch.
Please consider adding armhf support. :)
Regards
Konstantinos
-- System Information:
Debian Release: squeeze/sid
Architecture: armhf (armv7l)
Kernel: Linux 2.6.31.14-efikamx (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -ruN xserver-xorg-input-synaptics-1.2.2/debian/control xserver-xorg-input-synaptics-1.2.2.armhf/debian/control
--- xserver-xorg-input-synaptics-1.2.2/debian/control 2010-11-22 21:33:57.0 +
+++ xserver-xorg-input-synaptics-1.2.2.armhf/debian/control 2010-11-22 21:21:41.439766121 +
@@ -20,7 +20,7 @@
Vcs-Browser: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-synaptics.git
Package: xserver-xorg-input-synaptics
-Architecture: alpha amd64 arm armeb armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc sh4 sparc
+Architecture: alpha amd64 arm armeb armel armhf hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc sh4 sparc
Depends:
${shlibs:Depends},
${xinpdriver:Depends},
Bug#605764: xorg-server: Please add armhf support
Source: xorg-server
Severity: wishlist
Tags: patch
Hi,
The armhf port has reached a very good state (at 87%) at debian-ports.org,
and I'm now mass-filing bug reports to packages for armhf support.
Most packages just have to add armhf in the architecture field. The complete
list is in http://wiki.debian.org/ArmHardFloatTodo
While xorg-server already builds fine, the final udebs are missing from the
armhf
build. The package builds fine using the attached patch. Mind you, we do not
target
squeeze, so there is no rush. But please consider adding armhf support. :)
Regards
Konstantinos
-- System Information:
Debian Release: squeeze/sid
Architecture: armhf (armv7l)
Kernel: Linux 2.6.31.14-efikamx (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -ruN xorg-server-1.7.7.orig/debian//control xorg-server-1.7.7/debian//control
--- xorg-server-1.7.7.orig/debian//control 2010-12-03 09:04:51.0 +
+++ xorg-server-1.7.7/debian//control 2010-12-03 09:08:20.0 +
@@ -136,7 +136,7 @@
XC-Package-Type: udeb
Section: debian-installer
# exclude sparc because of linker errors
-Architecture: alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390
+Architecture: alpha amd64 armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390
Depends:
# merged: xserver-common (>= ${source:Version}),
xkb-data-udeb,
@@ -285,7 +285,7 @@
This package is built from the X.org xserver module.
Package: xserver-xfbdev
-Architecture: alpha amd64 arm armeb armel hppa i386 ia64 m32r m68k mips mipsel powerpc ppc64 sh3 sh3eb sh4 sh4eb sparc
+Architecture: alpha amd64 arm armeb armel armhf hppa i386 ia64 m32r m68k mips mipsel powerpc ppc64 sh3 sh3eb sh4 sh4eb sparc
Depends:
xserver-common (>= ${source:Version}),
${shlibs:Depends},
Bug#605841: xorg: Please add armhf support
Source: xorg Severity: wishlist Tags: patch Hi, The armhf port has reached a very good state (at 87%) at debian-ports.org, and I'm now mass-filing bug reports to packages for armhf support. Most packages just have to add armhf in the architecture field. The complete list is in http://wiki.debian.org/ArmHardFloatTodo The package builds fine using the attached patch. Mind you, we do not target squeeze, so there is no rush. But please consider adding armhf support. :) Regards Konstantinos -- System Information: Debian Release: squeeze/sid Architecture: armhf (armv7l) Kernel: Linux 2.6.31.14-efikamx (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -ruN xorg-7.5+8/debian/changelog xorg-7.5+8+armhf//debian/changelog --- xorg-7.5+8/debian/changelog 2010-10-02 12:20:30.0 + +++ xorg-7.5+8+armhf//debian/changelog 2010-10-03 16:04:56.0 + @@ -1,3 +1,9 @@ +xorg (1:7.5+8+armhf) unreleased; urgency=low + + * Add support for armhf. + + -- Konstantinos Margaritis Sun, 03 Oct 2010 16:03:32 + + xorg (1:7.5+8) unstable; urgency=low [ Julien Cristau ] diff -ruN xorg-7.5+8/debian/scripts/vars.armhf xorg-7.5+8+armhf//debian/scripts/vars.armhf --- xorg-7.5+8/debian/scripts/vars.armhf 1970-01-01 00:00:00.0 + +++ xorg-7.5+8+armhf//debian/scripts/vars.armhf 2010-10-03 16:21:51.0 + @@ -0,0 +1,14 @@ + +# This file is NOT a shell script. +# +# This file gets included by both debian/rules (make) AND the scripts in +# debian/scripts (Bourne shell). +XSERVER_XORG_VIDEO_DEPENDS="xserver-xorg-video-ati, \ + xserver-xorg-video-fbdev, \ + xserver-xorg-video-nv, \ + xserver-xorg-video-vesa, \ +" + +XSERVER_XORG_INPUT_DEPENDS="xserver-xorg-input-evdev, \ + xserver-xorg-input-synaptics, \ + xserver-xorg-input-wacom"
Re: X video drivers appropriate for ARM?
On 24 March 2011 23:57, Bryce Harrington wrote: > I am reviewing the default X drivers included in xorg for arm, and > notice there are a number which are pretty obscure and perhaps > irrelevant. I'm wondering if we can safely drop most of these from > xserver-xorg-video-all? FWIW, this BR has been filed for armhf, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605841 I guess it could be slightly modified for both armhf/armel, but in essence, that's the main idea. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikhVSGNW5hFWh=R=vahi8MSgEFqhA-bomiV=w=s...@mail.gmail.com
Bug#605841: xorg: Please add armhf support
Hi, any news about this bug report? Looking at it a second time and after the recent discussion in debian-arm [1], instead of -nv, -nouveau should be used -for those rare cases, an arm board with pci-e/agp is found and the user wants to try an nvidia card. I can send a new patch if you'd like, but really that's the only change. Regards Konstantinos [1]: http://lists.debian.org/debian-arm/2011/03/msg00074.html -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=_wtrj6aiwnzzxv7cyyctrgva...@mail.gmail.com
