[Bug 1528921] Re: rsync hangs on select(5, [], [4], [], {60, 0}
# rsync --version
rsync version 3.1.3 protocol version 31
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1528921
Title:
rsync hangs on select(5, [], [4], [], {60, 0}
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1528921/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1528921] Re: rsync hangs on select(5, [], [4], [], {60, 0}
I found these two probably related bug reports:
https://bugzilla.samba.org/show_bug.cgi?id=13913
https://bugzilla.samba.org/show_bug.cgi?id=13109
I am hitting this kind of bug when rsyncing a maildir (36000 files).
** Bug watch added: Samba Bugzilla #13913
https://bugzilla.samba.org/show_bug.cgi?id=13913
** Bug watch added: Samba Bugzilla #13109
https://bugzilla.samba.org/show_bug.cgi?id=13109
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1528921
Title:
rsync hangs on select(5, [], [4], [], {60, 0}
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1528921/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1323019]
Created attachment 6493 xfce4-panel-applicationsmenu-show_button_title.patch In my opinion, the bug is just a forgotten initialization of plugin->show_button_title variable. After adding the initialization in (see the one-line patch), the "Show button title" checkbox is checked upon adding the "Applications Menu" to the panel, and the title is shown as well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1323019 Title: "Applications Menu" title shows by default, despite unchecked box To manage notifications about this bug go to: https://bugs.launchpad.net/xfce4-panel/+bug/1323019/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1323019]
(In reply to Daniel Wilkins from comment #4) > Wow, this patch still applies? I figured it was just stuck languishing for > forever. It'd be easy enough to swap the defaults around, I just choose to > have the ui reflect the behavior that was actually happening rather than the > other way around; if there's actually any interest in merging the patch I'd > be happy to orient it whichever way the dev wants. It might be more tricky than it seems. I applied the patch directly (to xfce4-panel-4.12.0), it works. Then I played with it, and it can be reduced to only the following single change - gtk_widget_show (plugin->label); + if (plugin->show_button_title) + gtk_widget_show (plugin->label); The tricky part - for me - is that in the original source, in function "applications_menu_plugin_class_init", the "show-button-title" property is set to TRUE, yet in the end it is FALSE. So the "blind assumption" that the title (label) is on by default is perhaps not so blind. The real bug seems to be in the fact that the plugin->show_button_title is not "TRUE" even if it should be. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1323019 Title: "Applications Menu" title shows by default, despite unchecked box To manage notifications about this bug go to: https://bugs.launchpad.net/xfce4-panel/+bug/1323019/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1323019]
Though agreeably a minor bug, it is somehow confusing to the user. I've encountered it numerous times, when switching the label off after installation. Glad to see someone has been working on this. Tried the patch. The "Properties" dialog indeed correctly reflects the visual outcome. But I see a problem in the fact that the label becomes "off" by default. This effectively changes the default config (its final visual outcome for the user). Arguably, many (if not most) of the users are used to having the label present, and don't care whether this switch is working correctly or not. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1323019 Title: "Applications Menu" title shows by default, despite unchecked box To manage notifications about this bug go to: https://bugs.launchpad.net/xfce4-panel/+bug/1323019/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 36812]
Perhaps easier variant of the above workaround pertaining Alt+Shift is
to comment out the following (eight) lines in
/usr/share/X11/xkb/symbols/group
first change (search for lalt_lshift):
partial modifier_keys
xkb_symbols lalt_lshift_toggle {
virtual_modifiers Alt;
key LALT {
symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
virtualMods= Alt
};
//key LFSH {
//type[Group1]=PC_ALT_LEVEL2,
//symbols[Group1] = [ Shift_L, ISO_Next_Group ]
//};
};
second change (~15 lines below):
partial modifier_keys
xkb_symbols ralt_rshift_toggle {
virtual_modifiers Alt;
key RALT {
symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
virtualMods= Alt
};
//key RTSH {
//type[Group1]=PC_ALT_LEVEL2,
//symbols[Group1] = [ Shift_R, ISO_Next_Group ]
//};
};
then load the keymap, in my case
$ setxkbmap us,cz -option grp:alt_shift_toggle
or set it through gui (Change layout option=Alt+Shift in XFCE), or just
restart X server if you've already done so
Now shift+left alt (*in that order*, i.e. first press and hold any shift,
then press left alt) switches keyboard layout
alt+shift (first alt, then shift) works as a modifier (i.e.
shortcuts work), and does nothing in itself
alt+shift+tab works as it should
It would be nice to actually have a separate rule for this - titled
Shift+LAlt, available with -grp:shift_lalt_toggle, but unfortunatelly I don't
know how to modify the rules files..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/36812
Title:
Keyboard layout change on hotkeys press instead of release and do not
work well with shortcuts
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/36812/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 36812]
Found partial workaround today.
It _is_ possible to setup xkb so that the group (i.e. layout) switch
occurs on Shift+Alt (which means press and hold Shift, then press
Alt - order matters) - and still Alt+Shift+something (first alt,
then shift, then something) shortcuts work. All this without the need to
recompile xserver.
Here's what I did:
$ setxkbmap us,cz
(just load the layouts I want to the server, switching not working yet)
$ xkbcomp $DISPLAY xkbdesc
(list the xkb description from server to a file named xkbdesc)
Now two little changes to xkbdesc:
change1:
key LALT { [ Alt_L, Meta_L ] };
to
key LALT { [ Alt_L, ISO_Next_Group ] };
change2:
key RALT {
type[group1]= TWO_LEVEL,
type[group2]= ONE_LEVEL,
symbols[Group1]= [ Alt_R, Meta_R ],
symbols[Group2]= [ ISO_Level3_Shift ]
};
to
key RALT {
type[group1]= TWO_LEVEL,
type[group2]= TWO_LEVEL,
symbols[Group1]= [ Alt_R, ISO_Next_Group ],
symbols[Group2]= [ ISO_Level3_Shift, ISO_Next_Group ]
};
then
$ xkbcomp xkbdesc $DISPLAY
(load kbdesc to the server; ignore the warnings)
and voila! Shift+Alt (in that order) switches us-cz keyboard and
Alt+Shift+Tab works like it should.
I was actually quite surprised when I found this.
PS: Next time you start X, you can do just the last step, supposed you
keep the xkbdesc file.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/36812
Title:
Keyboard layout change on hotkeys press instead of release and do not
work well with shortcuts
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/36812/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 36812]
xkb should be extended to be able to recognize a sequence of key presses
and key releases and fire action upon it. Again, this would be an
extension, not a violation of current standard.
Currently, the group switching is defined in
/usr/share/X11/xkb/symbols/group with parts like
partial modifier_keys
xkb_symbols lalt_lshift_toggle {
virtual_modifiers Alt;
key LALT {
symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
virtualMods= Alt
};
key LFSH {
type[Group1]=PC_ALT_LEVEL2,
symbols[Group1] = [ Shift_L, ISO_Next_Group ]
};
};
The following is what this part of the file would look like after
appropiate changes in xkb code:
xkb_sequences lalt_lshift_toggle {
sequence { keydown LALT, keydown LFSH, keyup LFSH } = ISO_Next_Group;
sequence { keydown LFSH, keydown LALT, keyup LALT } = ISO_Next_Group;
}
For this to work
1) http://www.x.org/docs/XKB/XKBproto.pdf need to be extended with a small
chapter
2) http://cgit.freedesktop.org/xorg/xserver/tree/xkb - code the run time check
for sequences; changes to xkm format required
3) http://cgit.freedesktop.org/xorg/app/xkbcomp/tree/ - code the parsing of
xkb_sequences, keydown, and keyup keywords
At least this is my impression after a day of investigation. I know this seems
like unnecessarily big change compared to Ilya's patch. But, basically, that is
what I mean by clean solution. Unfortunatelly, it is more of a dream
solution, since I feel I will hardly be able to code this..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/36812
Title:
Keyboard layout change on hotkeys press instead of release and do not
work well with shortcuts
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/36812/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 36812]
As far as I can tell, it is already clear that XKB specifications needs
to be extended for this to be cleanly solved. While Ilya's hack works
for many people, and as much as I would like to see this fixed, I
understand why it is unacceptable to the developers. So, trying to delve
into XKB specs now; this page seems to be a good starting point to me:
https://wiki.archlinux.org/index.php/X_KeyBoard_extension
Also (as suggested by the author), copying info here from
https://bugzilla.redhat.com/show_bug.cgi?id=660254
Peter Hutterer 2011-01-05 22:07:57 EST
there is two problems with the tiny patch you mentioned. one, it's an
_explicit_ violation of the XKB specification (see section 4.4). two,
implementing this behaviour requires guesswork that I'm not sure is safe
in a number of setups.
Peter Hutterer 2011-01-06 17:12:05 EST
(In reply to comment #4)
But: doesn't fixing of a huge problem have a priority over preservation of a
holy spec?
it's a matter of figuring out the side-effects. a specification is a behaviour
promise, in this case in place for 15 years or so. a lot of users and apps rely
on the promised behaviour (in general, not necessarily this specific issue) and
breaking it is a dangerous thing because you may not know what else you break.
this is why we're hesitant to break the behaviour on purpose.
note that i'm not claiming that there is no problem, i'm just saying
it's the balance between a known problem and introducing new bugs that
potentially break current applications.
two,
implementing this behaviour requires guesswork that I'm not sure is safe in
a
number of setups.
What guesswork do you mean? Which setups can present problems?
BTW, I'm 100% sure that Ilya Murav'jev (patch author) will be glad to
cooperate.
afaict, the desired behaviour for a ctrl+shift groupchange is:
ctrl down → set Control modifier
shift down → set Shift modifier
if (other key pressed)
send event Contrl+Shift+other key
else if (ctrl || shift released)
change group
The XKB map for left control in this case is:
key LCTL { [ Control_L, ISO_Next_Group ] };
So whenever ISO_Next_Group is pressed, you still need to know which modifier to
set in case the group action isn't executed. The XkbSA_SetMod, XkbSA_LockMod,
etc. actions provide the modifiers set for a given key, hence why it works
currently. This information comes from the client when the xkb map is loaded
and is used to trigger the modifier flags for a given key. The XkbSA_LockGroup
behaviour (which is triggered at ISO_Next_Group) does not have this field
(adding it would break ABI), so you need to guess which modifiers to set if you
didn't trigger this action. This is the main stumbling point that I found and
if you look at Ilya's patch that's where he needs the big hack that I'm not
comfortable at all with it.
Now, I don't know if there are layouts where the modifier mask would be
different on the second level as opposed to the first (and Ilya's hack
or a similar attempt would fail completely) but there's so many layouts
that it'll take a while to get through them all.
And leaving the design bug because of purist reason looks really
strange...
there's two-ish ppl working on input at them moment, both are badly
overloaded because there's a lot of bugs and plenty new features that
ppl cry out for. so this bug has less to do with purist reasons, it's
more along the lines of i've got so many things to do that don't break
the spec, they get priority.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/36812
Title:
Keyboard layout change on hotkeys press instead of release and do not
work well with shortcuts
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/36812/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 334360] [NEW] Icon box doesn't display icons correctly when the panel is vertical
Public bug reported: Binary package hint: xfce4-panel Icon box always displays icons horizontally, even when the panel is vertical. Therefore, only one icon is accessible when the panel is vertical, rendering the Icon box widget unusable on a vertical panel. Steps to reproduce: -make panel vertical -have Icon box on it -open more than one application -only one icon will be visible accessible # lsb_release -rd Description:Ubuntu jaunty (development branch) Release:9.04 # apt-cache policy xfce4-panel xfce4-panel: Installed: 4.5.99.1-0ubuntu3 Candidate: 4.5.99.1-0ubuntu3 Version table: *** 4.5.99.1-0ubuntu3 0 ** Affects: xfce4-panel (Ubuntu) Importance: Undecided Status: New -- Icon box doesn't display icons correctly when the panel is vertical https://bugs.launchpad.net/bugs/334360 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
