gmane.linux.suse.opensuse.devel

Latest Tumbleweed kernel update 3.3.6 to 3.4.0 breaks cifs-mounting my NAS

Daniel Bischof — 2012-05-25T12:34:18

Hi,

the latest Tumbleweed kernel update 3.3.6 to 3.4.0 breaks cifs-mounting my 
NAS (used to work flawlessly with 3.3.6 and before). Accessing the NAS 
with smbclient still works.

Bug?

/etc/fstab excerpt
---
//garcon/media /home/mediarw cifs nodfs,user,noauto,user=daniel,uid=daniel,gid=users,credentials=/home/daniel/.smbcredentials,iocharset=utf8,file_mode=0755,dir_mode=0755 0 0
---

verbose error messages in /var/log/messages
---
May 24 18:36:39 kernel: [ 5128.053888] /[...]/linux-3.4/fs/cifs/cifsfs.c: Devname: //garcon/Volume_1/ flags: 0 
May 24 18:36:39 kernel: [ 5128.053921] /[...]/linux-3.4/fs/cifs/connect.c: iocharset set to utf8
May 24 18:36:39 kernel: [ 5128.053940] /[...]/linux-3.4/fs/cifs/connect.c: Username: daniel
May 24 18:36:39 kernel: [ 5128.053944] /[...]/linux-3.4/fs/cifs/connect.c: file mode: 0x1ed  dir mode: 0x1ed
May 24 18:36:39 kernel: [ 5128.054003] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 12 with uid: 0
May 24 18:36:39 kernel: [ 5128.054006] /[...]/linux-3.4/fs/cifs/connect.c: UNC: \\garcon\Volume_1 ip: 192.168.42.13
May 24 18:36:39 kernel: [ 5128.054020] /[...]/linux-3.4/fs/cifs/connect.c: Socket created
May 24 18:36:39 kernel: [ 5128.054022] /[...]/linux-3.4/fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x1b58
May 24 18:36:39 kernel: [ 5128.054335] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 13 with uid: 0
May 24 18:36:39 kernel: [ 5128.054347] /[...]/linux-3.4/fs/cifs/connect.c: Existing smb sess not found
May 24 18:36:39 kernel: [ 5128.054367] /[...]/linux-3.4/fs/cifs/cifssmb.c: secFlags 0x7
May 24 18:36:39 kernel: [ 5128.054381] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 114
May 24 18:36:39 kernel: [ 5128.054389] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 82
May 24 18:36:39 kernel: [ 5128.054428] /[...]/linux-3.4/fs/cifs/connect.c: Demultiplex PID: 3264
May 24 18:36:39 kernel: [ 5128.067828] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x67
May 24 18:36:39 kernel: [ 5128.067854] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=114 mid=1 state=4
May 24 18:36:39 kernel: [ 5128.067861] /[...]/linux-3.4/fs/cifs/cifssmb.c: Dialect: 2
May 24 18:36:39 kernel: [ 5128.067864] /[...]/linux-3.4/fs/cifs/cifssmb.c: negprot rc 0
May 24 18:36:39 kernel: [ 5128.067867] /[...]/linux-3.4/fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x80f3fd TimeAdjust: -3600
May 24 18:36:39 kernel: [ 5128.067870] /[...]/linux-3.4/fs/cifs/sess.c: sess setup type 1
May 24 18:36:39 kernel: [ 5128.067893] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 115
May 24 18:36:39 kernel: [ 5128.067895] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 244
May 24 18:36:39 kernel: [ 5128.081018] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x68
May 24 18:36:39 kernel: [ 5128.081081] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=115 mid=2 state=4
May 24 18:36:39 kernel: [ 5128.081093] /[...]/linux-3.4/fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
May 24 18:36:39 kernel: [ 5128.081103] /[...]/linux-3.4/fs/cifs/sess.c: UID = 100 
May 24 18:36:39 kernel: [ 5128.081110] /[...]/linux-3.4/fs/cifs/sess.c: bleft 62
May 24 18:36:39 kernel: [ 5128.081120] /[...]/linux-3.4/fs/cifs/sess.c: serverOS=Unix
May 24 18:36:39 kernel: [ 5128.081128] /[...]/linux-3.4/fs/cifs/sess.c: serverNOS=Samba 3.0.24
May 24 18:36:39 kernel: [ 5128.081136] /[...]/linux-3.4/fs/cifs/sess.c: serverDomain=MYWORKGROUP
May 24 18:36:39 kernel: [ 5128.081145] /[...]/linux-3.4/fs/cifs/sess.c: ssetup freeing small buf f2205e40
May 24 18:36:39 kernel: [ 5128.081153] /[...]/linux-3.4/fs/cifs/connect.c: CIFS Session Established successfully
May 24 18:36:39 kernel: [ 5128.081162] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 13) rc = 0
May 24 18:36:39 kernel: [ 5128.081174] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: in cifs_get_tcon as Xid: 14 with uid: 0
May 24 18:36:39 kernel: [ 5128.081186] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 117
May 24 18:36:39 kernel: [ 5128.081193] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 90
May 24 18:36:39 kernel: [ 5128.091411] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x36
May 24 18:36:39 kernel: [ 5128.091483] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=117 mid=3 state=4
May 24 18:36:39 kernel: [ 5128.091498] /[...]/linux-3.4/fs/cifs/connect.c: disk share connection
May 24 18:36:39 kernel: [ 5128.091509] /[...]/linux-3.4/fs/cifs/connect.c: nativeFileSystem=NTFS
May 24 18:36:39 kernel: [ 5128.091516] /[...]/linux-3.4/fs/cifs/connect.c: Tcon flags: 0x3 
May 24 18:36:39 kernel: [ 5128.091525] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: leaving cifs_get_tcon (xid = 14) rc = 0
May 24 18:36:39 kernel: [ 5128.091532] /[...]/linux-3.4/fs/cifs/connect.c: CIFS Tcon rc = 0
May 24 18:36:39 kernel: [ 5128.091538] /[...]/linux-3.4/fs/cifs/connect.c: DFS disabled (1)
May 24 18:36:39 kernel: [ 5128.091545] /[...]/linux-3.4/fs/cifs/cifssmb.c: In QFSDeviceInfo
May 24 18:36:39 kernel: [ 5128.091555] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 50
May 24 18:36:39 kernel: [ 5128.091563] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 72
May 24 18:36:39 kernel: [ 5128.092535] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x40
May 24 18:36:39 kernel: [ 5128.092580] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=50 mid=4 state=4
May 24 18:36:39 kernel: [ 5128.092596] /[...]/linux-3.4/fs/cifs/cifssmb.c: In QFSAttributeInfo
May 24 18:36:39 kernel: [ 5128.092607] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 50
May 24 18:36:39 kernel: [ 5128.092614] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 72
May 24 18:36:39 kernel: [ 5128.093353] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x4c
May 24 18:36:39 kernel: [ 5128.093389] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=50 mid=5 state=4
May 24 18:36:39 kernel: [ 5128.093403] /[...]/linux-3.4/fs/cifs/connect.c: build_unc_path_to_root: full_path=\\garcon\Volume_1
May 24 18:36:39 kernel: [ 5128.093416] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 117
May 24 18:36:39 kernel: [ 5128.093423] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 96
May 24 18:36:39 kernel: [ 5128.094927] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x30
May 24 18:36:39 kernel: [ 5128.094998] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=117 mid=6 state=4
May 24 18:36:39 kernel: [ 5128.095015] /[...]/linux-3.4/fs/cifs/connect.c: CIFS Tcon rc = 0 ipc_tid = 2
May 24 18:36:39 kernel: [ 5128.095024] /[...]/linux-3.4/fs/cifs/cifssmb.c: In GetDFSRefer the path \garcon\Volume_1
May 24 18:36:39 kernel: [ 5128.095038] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 50
May 24 18:36:39 kernel: [ 5128.095046] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 108
May 24 18:36:39 kernel: [ 5128.096086] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0xc8
May 24 18:36:39 kernel: [ 5128.096132] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=50 mid=7 state=4
May 24 18:36:39 kernel: [ 5128.096149] /[...]/linux-3.4/fs/cifs/cifssmb.c: Decoding GetDFSRefer response BCC: 145  Offset 56
May 24 18:36:39 kernel: [ 5128.096166] /[...]/linux-3.4/fs/cifs/cifssmb.c: num_referrals: 1 dfs flags: 0x3 ...
May 24 18:36:39 kernel: [ 5128.096205] /[...]/linux-3.4/fs/cifs/dns_resolve.c: dns_resolve_server_name_to_ip: resolved: garcon to 192.168.42.13
May 24 18:36:39 kernel: [ 5128.096319] /[...]/linux-3.4/fs/cifs/connect.c: iocharset set to utf8
May 24 18:36:39 kernel: [ 5128.096384] /[...]/linux-3.4/fs/cifs/connect.c: Username: daniel
May 24 18:36:39 kernel: [ 5128.096393] /[...]/linux-3.4/fs/cifs/connect.c: cifs_put_tcon: tc_count=1
May 24 18:36:39 kernel: [ 5128.096403] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 15 with uid: 0
May 24 18:36:39 kernel: [ 5128.096410] /[...]/linux-3.4/fs/cifs/cifssmb.c: In tree disconnect
May 24 18:36:39 kernel: [ 5128.096421] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 113
May 24 18:36:39 kernel: [ 5128.096429] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 39
May 24 18:36:39 kernel: [ 5128.097409] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x23
May 24 18:36:39 kernel: [ 5128.097447] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=113 mid=8 state=4
May 24 18:36:39 kernel: [ 5128.097459] /[...]/linux-3.4/fs/cifs/connect.c: cifs_put_smb_ses: ses_count=1
May 24 18:36:39 kernel: [ 5128.097470] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 16 with uid: 0
May 24 18:36:39 kernel: [ 5128.097478] /[...]/linux-3.4/fs/cifs/cifssmb.c: In SMBLogoff for session disconnect
May 24 18:36:39 kernel: [ 5128.097486] /[...]/linux-3.4/fs/cifs/transport.c: For smb_command 116
May 24 18:36:39 kernel: [ 5128.097493] /[...]/linux-3.4/fs/cifs/transport.c: Sending smb:  total_len 43
May 24 18:36:39 kernel: [ 5128.098346] /[...]/linux-3.4/fs/cifs/connect.c: RFC1002 header 0x27
May 24 18:36:39 kernel: [ 5128.098381] /[...]/linux-3.4/fs/cifs/transport.c: cifs_sync_mid_result: cmd=116 mid=9 state=4
May 24 18:36:39 kernel: [ 5128.098408] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 12) rc = 0
May 24 18:36:39 kernel: [ 5128.098418] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 17 with uid: 0
May 24 18:36:39 kernel: [ 5128.098426] /[...]/linux-3.4/fs/cifs/connect.c: UNC: (null) ip: (null)
May 24 18:36:39 kernel: [ 5128.098432] CIFS VFS: Connecting to DFS root not implemented yet
May 24 18:36:39 kernel: [ 5128.098550] /[...]/linux-3.4/fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 17) rc = -22
May 24 18:36:39 kernel: [ 5128.098559] CIFS VFS: cifs_mount failed w/return code = -22
---


Thanks,

--D.

Re: Security or Convenience? Defining a better policy

Vincent Untz — 2012-05-25T11:55:07

Le jeudi 24 mai 2012, à 10:01 +0200, Andreas Jaeger a écrit :

Sorry, forgot to reply. Not yet fixed, but we should take my patch. Will
do it.

Vincent

Re: Security or Convenience? Defining a better policy

Johannes Meixner — 2012-05-25T10:40:35

Hello,

On May 23 21:58 Marguerite Su wrote (excerpt):

If you want to do configuration changes without a password,

- you can do configuration changes by accident (prompting for
   a password would make you aware when something is no longer
   within the scope of what is considered as "usual work"),

- arbitrary persons who get even short time access to your machine
   can do configuration changes when it is running unattended
   (e.g. when you forgot by accident to lock your screen),
   i.e. arbitrary persons could hijack your machine when it is
   running unattended.

I am not against such a setting, I only like to point out
a security consequence.

If you like to do anything without providing a password,
you could work as root.

I mean this seriously.

What would be wrong with working as root if one likes to work
with unlimited permissions on one's own machine in one's own
secure internal network?

And for exceptional cases one could even jail root with software
like AppArmor and SELinux.


Kind Regards
Johannes Meixner

Re: Roles for security and convenience

Johannes Meixner — 2012-05-25T10:13:42

Hello,

On May 24 11:25 Andreas Jaeger wrote (excerpt):

What exactly does it mean "you are allowed"?

Can the user do particular configuration changes without
entering any password?

If yes, arbitrary persons who get even short time access
to the machine can do particular configuration changes
when it is running unattended (e.g. when the user forgot
by accident to lock his screen).

I am not against such a setting, I only like to point out
a security consequence.



Proposal for a "third preset":

* "Single password protected machine"
   Same as the "Admin configured server" but the root password
   is the same as the user password.
   "The user" in this case is the normal user account
   that is set up during installation and this user
   is considered to be "the owner" of the machine.

Then configuration changes could still require THE password
which is - from my point of view - sufficiently easy to use
and sufficiently secure because:

- The owner of the machine can do any configuration changes,
   he only must provide THE password.

- The owner of the machine cannot do configuration changes
   by accident because he must provide THE password.

- Arbitrary persons who get access to the machine cannot
   do configuration changes (i.e. arbitrary persons cannot
   hijack the machine when it is running unattended).

Of course it is already easily possible to set the root password
and the user password to the same value (so really no ingenious
new things here) but perhaps it helps if even such a simple but
a bit special kind of setup is offered under a ready-made "preset"?



I fear implementing roles becomes a huge piece of work - i.e. too much
for now (in particular too much with the limted manpower behind our
many YaST modules to implement roles therein).

I wish to start with something really simple but to really start
with implementing it right now and not discuss much longer about
an ultimate final solution.


Kind Regards
Johannes Meixner

Re: OSOC: plymouth for kiwi

Basil Chupin — 2012-05-25T09:12:44

[.........]

Oh, it's so great to have someone here with a great sense of humour :-) .

"I just started a little project: the openSUSE Spring of Code."

F-u-n-n-y :-D .

LIVE discs won't build and oS 12.2 Beta is having problems but there is 
a new project started :-) .

A sense of humour is, as I have always known, a great asset.

Psychiatrists and psychologists admit that "Laughter is the best medicine."

HAHAHA.....Love it :-D .

And this guffaw has done me 'a power of good' I have to admit.

Thank you, Stephan :-) .

[...............]

BC

OSOC: plymouth for kiwi

Stephan Kulow — 2012-05-25T07:52:02

Hi,

I just started a little project: the openSUSE Spring of Code.
It has many advantages over similiar projects, most prominently it's all
about honor and you don't have to care how to pay taxes on money.

And my first task to offer to the first promising candidate: plymouth
integration into kiwi (and installation-images). plymouth is integrated
into mkinitrd by now, but we have 2 other initrds that are worthy:

one is most likely easy: installation-images builds a pretty hard coded
list of files and packages to include and plymouth needs to replace
bootchart in there. Very similiar work to mkinitrd.

kiwi is a bit harder as it allows custom branding (e.g. for studio
integration) and as such builds bootsplash branding itself depending
on the branding, so plymouth integration is a bit more work.

Whoever picks the task: make sure to talk to snwint< at > and ms< at >suse.com

Greetings, Stephan

Re: Speeding up SRs process to devel projects

Stephan Kulow — 2012-05-25T03:49:05

Hi Brian,

This is a slightly different case though - it's about legal review in 
factory. We only have one person doing it
and he other things to do as well. So things tend to pile up pretty high 
for him.

I'm not really sure what the problem with jbigkit is - it's by far the 
oldest request in the queue and it looks
like pretty normal GPL and isn't even large (the two usual things that 
make legal review complicated).

So I can only guess it was really overlooked - among the other 90 
requests for legal review. I'll raise a flag.

Greetings, Stephan

Re: Roles for security and convenience

Claudio Freire — 2012-05-24T21:56:40

This one should allow the admin to grant some users some rights, and
instead of asking for root password, those users would be asked for
their own.

Re: Speeding up SRs process to devel projects

Brian K. White — 2012-05-24T21:46:52

Similarly I have given up on seeing jbig support in tifflib and hylafax 
etc in 12.2 or possibly even the next release after that.

6 weeks and counting...

https://build.opensuse.org/request/show/113336

I also have a tiff SR already in, but they are waiting for jbig to get 
into factory first before they can accept the tiff SR just into the tiff 
devel project let alone from there into factory. At this rate jbig won't 
be in factory until the middle of 12.2 life cycle, and tiff won't be 
actually using jbig until factory during 12.3 life cycle, and won't be 
in an actual release until 12.4 / 13.1 !

I prefer to treat people the way I want to be treated, so I didn't 
bother anyone, trusting that the obs sent them an email and that they 
are working through their lists in order, and I don't have to worry 
about mine getting lost, and so bothering people would only slow things 
down by distracting them from working through the stuff in front of me, 
not to mention simply annoying them.

Then when I finally did ask, they told me to just have patience too, so 
I have not mentioned it again till now.

I'm willing, but having patience and not bothering anyone hasn't been a 
working tactic lately.

Re: Security or Convenience? Defining a betterpolicy

Linda Walsh — 2012-05-24T19:30:22


---------------------

In order to better integrate SuSE as Windows Samba DC's,
it might be a good idea to use names and ID's associated with Windows's
groups.  Some examples from my own /etc/group file:

We don't need to use all of these groups, but we might consider
'trying' to reserve  them at some 'range' (ideally at offsets of 10000, or maybe
1000000

Some useful and potentially useful groups (with many examples, but
likely NOT a thorough list -- and also it would be likely that
many of these would only be needed in more complex setups:

(names taken verbatim from published MS documents -- spaces work fine --
backslashes also work -- they are literals, not quoting characters)

Cert Publishers:!:517:root
-- those who can *create( 'signing' certs for a domain (or sub domain)
Schema Admins:!:518:root
-- LDAP?  CIM?
Enterprise Admins:!:519:root:MyDomain\lawalsh
domain-wide root
Group Policy Creator Owners:!:520:root
Polkit editors/creators
Administrators:!:544:root,Administrator,Domain Admins,Enterprise Admins
machine-level root
Account Operators:!:548:backup,root
root level access on local machine
Server Operators:!:549:
start/stop services; restart machine
Print Operators:!:550:
Add / modify print devices & queues
Backup Operators:!:551:backup
who can run backup and restore (which need  DAC override + SET_LABEL )
Remote Desktop Users:!:555:root
Those who can login remotely to a machine and get a full
X-server (xrdp, remote X (xdmcp)) (might be different than those who
can run ssh)
Network Configuration Operators:!:556:
if/ip commands + config -- firewall... etc...

Distributed Com User:!:562:
A group to control/allow access to RPC resources apart from
per-user access
Web Services:!:568:
apache/lighttpd -- or any other web server...
Cryptographic Operators:!:569:
Those who can add new certs (not create them) to a machine or group

Re: Roles for security and convenience

Robert Schweikert — 2012-05-24T18:54:09

I think having this type of preset policy model may suffice. For 
everything else we'd provide the super flexible dialog dialog. I cannot 
not see where a role based model will provide a simple and quick at 
install time. The preset "access model" as described above can be a 
simple one click selection at install time, with the more detail 
settings dialog hanging of this dialog and activated by clicking on 
"Advanced Settings".

I don't think we need to do any more than the combination of the two, 
i.e. preset "access model" + flexible select per function each user's 
allowed access.

Later,
Robert

Re: Re: Proposal to replace default scim/ibus input methods in ISOs with alternatives.

Marguerite Su — 2012-05-24T16:02:04

Clever boy. (then why you flooded so many?


You're welcome.

Oh by the way: Welcome to openSUSE world.

And use openSUSE example.

Hope it helps.

Marguerite

Re: Nmap v6

James Knott — 2012-05-24T15:58:16

tnx

Re: Re: Proposal to replace default scim/ibus input methods in ISOs with alternatives.

Ma Xiaojun — 2012-05-24T15:54:49

I'd say it is really hard to discuss any problems in a list have
messages like the following.
http://lists.opensuse.org/opensuse-factory/2012-05/msg00478.html

As long as I made my points clear, I just need to wait for others' response.

Thank you all.

Re: Re: Proposal to replace default scim/ibus input methods in ISOs with alternatives.

Marguerite Su — 2012-05-24T15:44:02

You said it's "introduction".


"And I think this case is common."

"so I made this online survey to see if everyone is like me."

Read it again carefully. I'm not your grammar teacher.

Please stop flooding this thread.


Hi, coolo,

Please offer some help here.

This one is keeping off-topic in our factory list.


Marguerite

Re: Security or Convenience? Defining a better policy

Martin Schlander — 2012-05-24T15:37:51

Torsdag den 24. maj 2012 10:03:00 Andreas Jaeger skrev:

Done.

http://en.opensuse.org/openSUSE:Security_use_cases#Writing_to_NTFS

Re: Re: Proposal to replace default scim/ibus input methods in ISOs with alternatives.

Ma Xiaojun — 2012-05-24T15:34:18

It is obvious that you try to "educate" users in this survey.
You explicilty said which IMF is most popular in different regions in
the introduction.
If you know such fact beforehand, why bother doing the survey anyway?

Re: Nmap v6

Vitezslav Cizek — 2012-05-24T15:32:13

* V Čtvrtek 24. květen 2012, 17:18:58 [CEST] James Knott napsal:
It is already in Factory.
So it will appear in 12.2.

Re: Nmap v6

Togan Muftuoglu — 2012-05-24T15:30:58

depends your typing speed

osc bco network:utilities nmap

rework spec for the new nmap version
osc service localrun download_files
osc vc
osc build
fix if any errors
rm previous nmap
osc ar
osc ci
osc submitpac

Togan

Re: Re: Proposal to replace default scim/ibus input methods in ISOs with alternatives.

Marguerite Su — 2012-05-24T15:20:56

That's called briefing. not imagination like you did.


The survey is well tested and serves as basis for discussion here.

And it's shared between IM developers and maintainers.

They took it as a trend study. (including IBus co-founder)

So you have to well prove "baised". Take time to find solid evidences
for openSUSE.

Your very beginning post shows no related data with openSUSE.

Let me claim it again: use openSUSE example.

Of course we openSUSE M17N team take maintenance as the first priority.

That's common policy.


Let me claim it again: use openSUSE example. and SR talks.

You're really good at avoiding important things and asking same questions.

You very first post is off-topic from this thread.

Re: Status: Beta

Roman Bysh — 2012-05-24T15:19:53

And 12.2 will be celebrating the 20th anniversary. ;-)

--
Cheers!

Roman
---------------------------------------------------------------
openSUSE -- Get it! Discover it! Share it!
---------------------------------------------------------------
http://linuxcounter.net/    #179293