Contents
i18n problems
i18n/l10n confusion
in doc and mailing lists there is confusion about i18n and l10n; i18n is incorrectly used in place of l10n (aka localization or translation), leaving no clear place for real i18n problems (eg: keyboard problems, inconsistencies in the way some variables are handled by different environments, etc)
see: Whats is i18n, what is l10n
locale setting by various tools is not synchronized
description and ideas at https://bugs.mageia.org/show_bug.cgi?id=10094#c5
keyboard setting by various tools is not synchronized
description and ideas at https://bugs.mageia.org/show_bug.cgi?id=10094#c5
also: Feature:SystemdTidyups#Keyboard (I think current systemd is below the level of drak tools; improvement of systemd for X11 keyboard info should be done with upstream (maybe implementing ideas above)).
old recurrent problem of X11 not knowing all glibc locales
description and ideas at https://bugs.mageia.org/show_bug.cgi?id=7797#c13
perl and stdout/stdin
perl when run in utf-8 (which is nowadays the default everywhere) still handles writing to stdout or reading from stdin as iso-8859-1; it affects drak tools and 3d party tools too (eg: gscan2pdf when reading (trough stdin) the output of gocr)
couldn"t it be fixed in perl proper (that is, upstrea)? If system is in utf-8; then stdin and stdout must be in utf-8 too; perl should not do any charset conversion at all. perl seems to be the only brick (at least the only modern brick) of the distribution that still has problems in a full utf-8 system.
note that reading/writing to a file is ok; and all gui interaction too; it is only plain old stdin/stdout (stderr too probably) that is broken
others
gdm 2.20
some people prefer old gdm 2.20 (over new gdm 3.x). package gdm-220 has been dropped from Mageia, probably as it conflicts with gdm and is no longer mantained.
I'm working on a modified package (I'll call it "gdm220") that would have several fixings:
- changed some dir/files names to make it cohexist with standard gdm
- drop consolekit (obsolete)
- use logind (throug pam) for session management
- use dbus org.freedesktop.Accounts for face icons reading/updating (code copied from gnome-control-center v3)
- enabled ipv6 at build time
advantages: it doesn't use gtk3/gnome3 librairies, just gtk2/gnome2 ones; so it may be a good DM choice for a MATE environment
gdmXnest doesn"t work (black screen); maybe that subpackage shouldn't be packaged
/var/lib/rpm-state/ dir
according to RPM docs, any install/update temporary file or directory should be created in a directory %{localstatedir}/lib/rpm-state/%{name}
if the rpm scripts use it, then the directory has to be owned and ghosted by the package:
%install
...
mkdir -p %{buildroot}%{localstatedir}/lib/rpm-state/%{name}
%files
...
%dir %ghost %{localstatedir}/lib/rpm-state/%{name}
the %{localstatedir}/lib/rpm-state dir itself should be owned (in normal way) by "rpm" or "filesystem"
ideas for updating complex packages
Sometimes an upgrade breaks things because the functionality included in old package is splitt across several ones in new version. eg: bug#6805
We could just install them all, but that is suboptimal.
It is a "requires" problem; but the actual list of requires depends on the actual configuration of the pre-updated system. A layer before running urpmi is needed in order to inject extra dependencies.
Idea: have an extra branch in the repository tree with scripts; when agiven package "foo" is selected for upgrade in rpmdrake; then check if a script "upgrade-foo-oldver-to-newver" exists (eg: "apache-2.2-to-2.4"); if it exists, then download it, and run it (script should be signed with gpg key for security).
Such scripts should:
- check existing configuration to see if module/functionality is being used; if yes, add a dependency for given package (for exemple writing it to a file /var/lib/rpm-state/<script name>/dependencies )
- check existing configuration to see if some sort of directory symlinking or config file modification is needed; if yes create a script on /var/lib/rpm-state/<package name>/run-{pre,post}trans (the package name being the one of the selected rpm, and/or any of the newly found dependencies, as needed)
after running the script rpmdrake would load the /var/lib/rpm-state/<script name>/dependencies file, add the new dependencies to its list, remove the file and directory, and proceed with next.
the same could be done for install, if "foo" is selected, look for a "install-foo" script
an rpm package that could use such upgrade/install path should have:
%pretrans
if [ -r %{localstatedir}/lib/rpm-state/%{name}/run-pretrans ]; then
sh -c %{localstatedir}/lib/rpm-state/%{name}/run-pretrans \
&& rm -f %{localstatedir}/lib/rpm-state/%{name}/run-pretrans
fi
%postrans
if [ -r %{localstatedir}/lib/rpm-state/%{name}/run-posttrans ]; then
sh -c %{localstatedir}/lib/rpm-state/%{name}/run-posttrans \
&& rm -f %{localstatedir}/lib/rpm-state/%{name}/run-posttrans
rmdir %{localstatedir}/lib/rpm-state/%{name}
fi
advantages:
- improving update scripts to take care of special cases don't need rewritting of the rpm itself
- allows for fine granularity of which rpm packages to actually install:
- in hardware support for exemple, if "task-wireless" is chosen, instead of having it forcing a lot of hardware specific rpms, run a "install-task-wireless" script that detects wireless device(s) present on the system; and depending on what is found add the needed dependencies
- it could detect the desktop environment presents and install a tools for them
- that granularity is provided granularly (for each package/task independently) and not centralized into a bloated control center
the scripts may have dependencies too (eg: "install-task-wireless" may require harddrake and udev); and need to be gpg signed; so maybe providing them as small rpm packages would be an easy way to achieve that; rpmdrake/urpmi could then install them, the script would run whatever is needed, then they could be removed when the actual rpm is installed (eg: "apache" rpm would have an "Obsoletes: update-apache-2.2-to-2.4").
systemd
ideas/improvements to tell upstream
journalctl
in journalctl, when output is displayed, a lot of space is lost with the hostname. a command line option --display-hostname={no,short,long,auto} would be nice. With the default being "auto"; and it being:
- not displaying it if the journal has only local logs and journalctl is run locally (since logind keep track of localness we know it)
- displaying only short hostname if journal has logs for various hosts with same domain, or if journalctl run remotely and remote host and local host have same domain
dbus integration
userdrake
- use org.freedesktop.Accounts service: #10310
networkmanager
after upgrading my network settings (not very, I agree) where completly broken: #10269
ok, after quite in-depth looking, to both drakx-net tools and NetworkManager, it shows that drak-net is lagging behind. So I involved on the task of making drakx-net work as it should:
- support in gui at least all the major features possible trough raw ifcfg files
- don't delete valid ifcfg features (drak-net was years behind in its knowledge of those)
- add IPv6 support
- change internal data structure to use same structure as NM (which is structured into sections), instead of current copy of raw ifcfg (which has no structure, all is in a single plain space, and the lack of arrays or hashes is a big burden)
2d wave goals:
- add support for all existing networking types (not just the ones currently available trough raw ifcfg)
- dbus integration with NM service
- be able to do a distro install by network on an IPv6 only setup
bug tracking
i18n bus
- #3723 (incorrect detection of locales by liveDVD/liveCD installer)
- #5749 (lack of lcoale fallback mechanism)
- #10344 (i18n problem due to build with wrong *-devel package; easy to fix, changing spec file and rebuild as told in the bug report)
- #10458 (patch to use systemd (localectl) service for keyboard registration)
others
- #6056 (drakclock: text, systemd and ntp server selection improvement)
- #9575 (gnome-control-center provides same functionality as drakclock, but doesn't trigger install of ntp.rpm: close as INVALID? how to trigger it from non mageia tools? to look at how gstreamer does)
- #10178 (minor, problem with rpm script in some update cases)
- #10231 (seems a local corruption problem; to be closed as INVALID if no feedback)
- #10269 (drakx-net reworking)
- #10590 (text2bool)
- #10310 (use dbus service for user account info (partial patch to support user icon provided); maybe it has to be done in libuser?)
- #10384 (wrong types, related to #10176, patch provided)
- #10436 (sometimes total package count used in progressbar gets wrong)
- #10425 (xf86main::main::Xtest may not work if from an older version?)
- #10442 (virtualbox X11 crash on cauldron)
- #10486 (dbus service domain changed; fix needed for obexd to work, easy)
- #10487 (patch to fix crash in gvfsd-obexftp)
- #10488 (new packages needed for broadcom usb firmware loading, easy)
- #10552 (rgrep is broken)
- #9960 (NM problem)
