Bug#1029594: Fails to authenticate mit o365

2023-02-06 Thread Harshula

Hi Carsten,

Authentication successfully completed with your test build:
https://people.debian.org/~tijuca/thunderbird-102.7.1+1/

Thanks,
Harshula

On 6/2/23 14:05, Harshula wrote:

Hi Carsten,

1) Did you use Thunderbird's Release Candidate Build 1 instead of 
Release Candidate Build 2 for the Debian 102.7.1 release [1]? It appears 
you uploaded the Debian package on the "2023-01-24" [2]. Build 2 was 
only released on the 31st of January.


$ diff -rq build1/thunderbird-102.7.1/comm/mailnews/base/src/ 
debian/thunderbird-102.7.1/comm/mailnews/base/src/


$ diff -rq build2/thunderbird-102.7.1/comm/mailnews/base/src/ 
debian/thunderbird-102.7.1/comm/mailnews/base/src/
Files build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm and 
debian/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm differ
Files 
build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm 
and 
debian/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm 
differ


2) The authentication successfully completed with the upstream build of 
Thunderbird 102.7.1 [3], whereas the authentication was in an infinite 
loop with the Debian build of Thunderbird 102.7.1.


Regards,
Harshula

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1814536
[2] 
https://tracker.debian.org/news/1413005/accepted-thunderbird-110271-1-source-into-unstable/
[3] 
https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/linux-x86_64/en-US/thunderbird-102.7.1.tar.bz2




Bug#1029594: Fails to authenticate mit o365

2023-02-05 Thread Harshula

Hi Carsten,

1) Did you use Thunderbird's Release Candidate Build 1 instead of 
Release Candidate Build 2 for the Debian 102.7.1 release [1]? It appears 
you uploaded the Debian package on the "2023-01-24" [2]. Build 2 was 
only released on the 31st of January.


$ diff -rq build1/thunderbird-102.7.1/comm/mailnews/base/src/ 
debian/thunderbird-102.7.1/comm/mailnews/base/src/


$ diff -rq build2/thunderbird-102.7.1/comm/mailnews/base/src/ 
debian/thunderbird-102.7.1/comm/mailnews/base/src/
Files build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm and 
debian/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm differ
Files 
build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm 
and 
debian/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm differ


2) The authentication successfully completed with the upstream build of 
Thunderbird 102.7.1 [3], whereas the authentication was in an infinite 
loop with the Debian build of Thunderbird 102.7.1.


Regards,
Harshula

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1814536
[2] 
https://tracker.debian.org/news/1413005/accepted-thunderbird-110271-1-source-into-unstable/
[3] 
https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/linux-x86_64/en-US/thunderbird-102.7.1.tar.bz2



https://download-origin.cdn.mozilla.net/pub/thunderbird/candidates/102.7.1-candidates/build1/source/

Filethunderbird-102.7.1.source.tar.xz   477M24-Jan-2023 03:33
Filethunderbird-102.7.1.source.tar.xz.asc   833 24-Jan-2023 03:33

$ sha256sum thunderbird-102.7.1.source.tar.xz
74cbf32140cbbd7954093f7adc1a1d0cf8a9b0f77dfd9d344540a111fed9ac20 
thunderbird-102.7.1.source.tar.xz



https://download-origin.cdn.mozilla.net/pub/thunderbird/candidates/102.7.1-candidates/build2/source/

Filethunderbird-102.7.1.source.tar.xz   487M31-Jan-2023 15:46
Filethunderbird-102.7.1.source.tar.xz.asc   833 31-Jan-2023 15:46

$ sha256sum thunderbird-102.7.1.source.tar.xz
00c9a215ec99b4ce1683c8581b5bb44759ad31cb1303bdec173c053fcee27c91 
thunderbird-102.7.1.source.tar.xz



https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/source/

Filethunderbird-102.7.1.source.tar.xz   487M01-Feb-2023 02:10
Filethunderbird-102.7.1.source.tar.xz.asc   833 01-Feb-2023 02:10

$ sha256sum thunderbird-102.7.1.source.tar.xz
00c9a215ec99b4ce1683c8581b5bb44759ad31cb1303bdec173c053fcee27c91 
thunderbird-102.7.1.source.tar.xz

$ diff -rq build1/thunderbird-102.7.1/ build2/thunderbird-102.7.1
Files build1/thunderbird-102.7.1/comm/chat/protocols/xmpp/xmpp-base.jsm and 
build2/thunderbird-102.7.1/comm/chat/protocols/xmpp/xmpp-base.jsm differ
Files build1/thunderbird-102.7.1/comm/mail/base/content/mailContextMenus.js and 
build2/thunderbird-102.7.1/comm/mail/base/content/mailContextMenus.js differ
Files build1/thunderbird-102.7.1/comm/mail/base/content/utilityOverlay.js and 
build2/thunderbird-102.7.1/comm/mail/base/content/utilityOverlay.js differ
Files 
build1/thunderbird-102.7.1/comm/mail/components/compose/content/MsgComposeCommands.js
 and 
build2/thunderbird-102.7.1/comm/mail/components/compose/content/MsgComposeCommands.js
 differ
Only in 
build2/thunderbird-102.7.1/comm/mail/components/extensions/test/browser: 
browser_ext_compose_bug1804796.js
Files 
build1/thunderbird-102.7.1/comm/mail/components/extensions/test/browser/browser.ini
 and 
build2/thunderbird-102.7.1/comm/mail/components/extensions/test/browser/browser.ini
 differ
Files build1/thunderbird-102.7.1/comm/mail/themes/windows/mail/mailWindow1.css 
and build2/thunderbird-102.7.1/comm/mail/themes/windows/mail/mailWindow1.css 
differ
Files build1/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm and 
build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2.jsm differ
Files build1/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm and 
build2/thunderbird-102.7.1/comm/mailnews/base/src/OAuth2Providers.jsm differ
Files build1/thunderbird-102.7.1/comm/mailnews/compose/src/nsMsgCompose.cpp and 
build2/thunderbird-102.7.1/comm/mailnews/compose/src/nsMsgCompose.cpp differ
Files 
build1/thunderbird-102.7.1/comm/mailnews/import/modules/AddrBookFileImporter.jsm
 and 
build2/thunderbird-102.7.1/comm/mailnews/import/modules/AddrBookFileImporter.jsm
 differ
Files 
build1/thunderbird-102.7.1/comm/mailnews/import/test/unit/resources/addressbook.json
 and 
build2/thunderbird-102.7.1/comm/mailnews/import/test/unit/resources/addressbook.json
 differ
Only in build2/thunderbird-102.7.1/comm/mailnews/import/test/unit/resources: 
dos_vcard_addressbook.vcf
Files 
build1/thunderbird-102.7.1/comm/mailnews/import/test/unit/test_AddrBookFileImporter.js
 and 
build2/thunderbird-102.7.1/comm/mailnews/import/test/unit/test_AddrBookFileImporter.js
 differ
Files build1/thunderbird-102.7.1/sourcestamp.txt and 
build2/thunderbi

Bug#892333: Bug#892350: Your package FTBFS with freetype 2.9.1

2018-10-20 Thread Harshula
Hi Hugh,

1) Does the following patch to libotf fix the issue you are seeing?

# Use pkg-config instead of freetype-config
--- a/configure.ac
+++ b/configure.ac
@@ -49,14 +49,14 @@
 AC_FUNC_MALLOC

 # Check for Freetype2 usability.
-AC_CHECK_PROG(HAVE_FREETYPE_CONFIG, freetype-config, yes)
-if test "x$HAVE_FREETYPE_CONFIG" = "xyes"; then
-  FREETYPE_INC=`freetype-config --cflags`
+AC_CHECK_PROG(HAVE_PKG_CONFIG, pkg-config, yes)
+if test "x$HAVE_PKG_CONFIG" = "xyes"; then
+  FREETYPE_INC=`pkg-config freetype2 --cflags`
   CPPFLAGS="$CPPFLAGS $FREETYPE_INC"
   AC_CHECK_HEADER(ft2build.h, HAVE_FREETYPE=yes,
  HAVE_FREETYPE=no CPPFLAGS=$save_CPPFLAGS)
   if test "x$HAVE_FREETYPE" = "xyes" ; then
-FREETYPE_LD_FLAGS=`freetype-config --libs`;
+FREETYPE_LD_FLAGS=`pkg-config freetype2 --libs`;
 LIBS="$LIBS $FREETYPE_LD_FLAGS"
 AC_CHECK_LIB(freetype, FT_Init_FreeType, HAVE_FREETYPE=yes,
 HAVE_FREETYPE=no)


2) I've uploaded binary and source packages to http://hj.id.au/debian/
for you to test. If you are happy with it, I'll upload it to the Debian
archives.

Thanks,
#

On 19/10/18 11:45 pm, Hugh McMaster wrote:
> Control: severity -1 serious
> 
> Dear maintainer,
> 
> Freetype 2.9.1-2 has been in experimental for three weeks now. As it is 
> working well, I have decided to upload the package to unstable within the 
> next two to three weeks.
> 
> A rebuild of your package with freetype 2.9.1 installed confirmed that your 
> package will FTBFS once the new version of freetype enters unstable. In 
> almost all cases, this build failure was caused by the configure script not 
> detecting the freetype libraries, as freetype-config is not shipped in 2.9.1.
> 
> Given the build failure and upcoming upload of freetype 2.9.1, I am raising 
> the severity of this bug to Serious.
> 
> Please use pkg-config to detect freetype.
> 
> Thank you
> 



Bug#640713: [Pkg-ime-devel] Bug#640713: Bug#640713: ibus-m17n: diff for NMU version 1.3.2-1.1

2011-09-26 Thread Harshula
Hi,

On Tue, 2011-09-27 at 10:29 +0800, Asias He wrote:

 Yes. You are right. I should use Chinese - py (m17n) to inpurt Han
 characters. I have uploaded ibus-m17n 1.3.3-1. Can you try it when the
 upload goes to the archive?

Did a quick test and ibus-m17n 1.3.3-1 you uploaded works fine. The
surrounding text support (STS) works fine too. Thanks for all your
efforts getting IBus  ibus-m17n updated.

If you have any problems with ibus-m17n and/or m17n in the future, feel
free to contact me.

cya,
#




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



Bug#640713: [Pkg-ime-devel] Bug#640713: Bug#640713: ibus-m17n: diff for NMU version 1.3.2-1.1

2011-09-26 Thread Harshula
On Tue, 2011-09-27 at 10:46 +0800, Asias He wrote:

 You are welcome to co-maintain ibus-m17n since you are the
 maintainer of m17n-lib and other ibus-* package if you are interested.

The upstream maintainer Daiki (CC'd) might be interested. ;-)

cya,
#




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



Bug#640713: [Pkg-ime-devel] Bug#640713: Bug#640713: ibus-m17n: diff for NMU version 1.3.2-1.1

2011-09-25 Thread Harshula
Hi,

On Sun, 2011-09-25 at 00:08 +0800, Asias He wrote:

 I have packaged the 1.3.3 upstream version. However, it does not quite work.
 It seems the 1.3.3 upstream version has some bugs. I've filed a bug against 
 it.
 
http://code.google.com/p/ibus/issues/detail?id=1311

I've been using ibus-m17n for a week and a bit using my own package
(http://harshula.com/debian/) and I have no problems typing in Sinhala
using the m17n Sinhala layouts.

Which m17n MIM file did you test? Was it zh-pinyin.mim (PinYin)? If so
note:

(description Input method for Chinese Pinyin characters.
Note that it's not for inputting Han characters.
)

If you could tell me which MIM you used, I can test it and talk to the
relevant people.

cya,
#




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



Bug#618080: m17n-lib: FTBFS: m17n-X.c:1103: undefined reference to `FcPatternCreate'

2011-03-14 Thread Harshula
Hi Lucas,

On Sun, 2011-03-13 at 18:15 +0100, Lucas Nussbaum wrote:

  m17n-X.c:2199:10: warning: cast from pointer to integer of different size
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. 
  -DM17NDIR=\/usr/share/m17n\ -DM17N_MODULE_DIR=\/usr/lib/m17n/1.0\ 
  -DGETTEXTDIR=\/usr/share/locale\ -I/usr/include/freetype2 
  -I/usr/include/freetype2 -I/usr/include/freetype2 -I/usr/include/libxml2 -g 
  -O2 -MT m17n-X.lo -MD -MP -MF .deps/m17n-X.Tpo -c m17n-X.c -o m17n-X.o 
  /dev/null 21
  mv -f .deps/m17n-X.Tpo .deps/m17n-X.Plo
  /bin/bash ../libtool --tag=CC   --mode=link gcc  -g -O2 -avoid-version 
  -module -Wl,--as-needed -Wl,-z,defs -o libm17n-X.la -rpath 
  /usr/lib/m17n/1.0 m17n-X.lo -lSM -lICE  -lXt -lX11  -lXft   
  ../src/libm17n-core.la ../src/libm17n.la ../src/libm17n-flt.la 
  ../src/libm17n-gui.la -ldl 
  libtool: link: gcc -shared  .libs/m17n-X.o   -Wl,-rpath 
  -Wl,/build/user-m17n-lib_1.6.2-2-amd64-d6MpLi/m17n-lib-1.6.2/src/.libs -lSM 
  -lICE -lXt -lX11 -lXft ../src/.libs/libm17n-core.so ../src/.libs/libm17n.so 
  ../src/.libs/libm17n-flt.so ../src/.libs/libm17n-gui.so -ldl  
  -Wl,--as-needed -Wl,-z -Wl,defs   -Wl,-soname -Wl,libm17n-X.so -o 
  .libs/libm17n-X.so
  .libs/m17n-X.o: In function `xft_open_font':
  /build/user-m17n-lib_1.6.2-2-amd64-d6MpLi/m17n-lib-1.6.2/src/m17n-X.c:1103: 
  undefined reference to `FcPatternCreate'
  /build/user-m17n-lib_1.6.2-2-amd64-d6MpLi/m17n-lib-1.6.2/src/m17n-X.c:1104: 
  undefined reference to `FcPatternAddString'
  /build/user-m17n-lib_1.6.2-2-amd64-d6MpLi/m17n-lib-1.6.2/src/m17n-X.c:1105: 
  undefined reference to `FcPatternAddDouble'
  /build/user-m17n-lib_1.6.2-2-amd64-d6MpLi/m17n-lib-1.6.2/src/m17n-X.c:1106: 
  undefined reference to `FcPatternAddBool'
  collect2: ld returned 1 exit status

I had already asked upstream about this and I am waiting for feedback.
They are located in Japan and there are DNS timeouts.

The fix that worked for me was:

diff --git a/src/Makefile.am b/src/Makefile.am
index 3de7237..c3ab4a7 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -90,7 +90,7 @@ module_LTLIBRARIES = libm17n-X.la libm17n-gd.la
 X_LD_FLAGS = ${X_PRE_LIBS} ${X_LIBS} @X11_LD_FLAGS@ ${X_EXTRA_LIBS}
 
 libm17n_X_la_SOURCES = m17n-X.h m17n-X.c
-libm17n_X_la_LIBADD = ${X_LD_FLAGS} @XFT2_LD_FLAGS@ 
${top_builddir}/src/libm17n-core.la ${top_builddir}/src/libm17n.la 
${top_builddir}/src/libm17n-flt.la ${top_builddir}/src/libm17n-gui.la
+libm17n_X_la_LIBADD = ${X_LD_FLAGS} @XFT2_LD_FLAGS@ @FONTCONFIG_LD_FLAGS@ 
${top_builddir}/src/libm17n-core.la ${top_builddir}/src/libm17n.la 
${top_builddir}/src/libm17n-flt.la ${top_builddir}/src/libm17n-gui.la
 libm17n_X_la_LDFLAGS = -avoid-version -module
 
 libm17n_gd_la_SOURCES = m17n-gd.c

The patch adds @FONTCONFIG_LD_FLAGS@ to libm17n_X_la_LIBADD.

I'm not sure if I should upload immediately or wait for upstream
feedback?

cya,
#




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



Bug#473957: scim-m17n: FTBFS: libtool: link: `/usr/lib/libxml2.la' is not a valid libtool archive

2008-04-04 Thread Harshula
reassign 473957 libm17n-dev 1.3.4-1
thanks

Hi,

libm17n-dev needs to Depend on libxml2-dev and libthai-dev.

cya,
#




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#473957: scim-m17n: FTBFS: libtool: link: `/usr/lib/libxml2.la' is not a valid libtool archive

2008-04-02 Thread Harshula
Hi,

On Wed, 2008-04-02 at 12:52 +0200, Lucas Nussbaum wrote:

 Relevant part:
  /bin/sh ../libtool --tag=CXX --mode=link i486-linux-gnu-g++  -Wall -g -O2  
  -Wl,-z,defs -o m17n.la -rpath /usr/lib/scim-1.0/1.4.0/IMEngine 
  -avoid-version -rpath /usr/lib/scim-1.0/1.4.0/IMEngine -module 
  -export-symbols-regex ^[^_].* -lscim-1.0 -lm17n -lm17n-core   
  m17n_la-scim_m17n_imengine.lo  
  grep: /usr/lib/libxml2.la: No such file or directory
  /bin/sed: can't read /usr/lib/libxml2.la: No such file or directory
  libtool: link: `/usr/lib/libxml2.la' is not a valid libtool archive
  make[3]: *** [m17n.la] Error 1

This maybe related to my changes to m17n-lib. I'll verify and if
necessary reassign this bug.

cya,
#




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#466922: How to resolve critical situation

2008-03-05 Thread Harshula
Hi,

This whole issue started from the fix to Bug #465661 (m17n-db:
binary-without-manpage usr/bin/m17n-db) because m17n-docs is non-free.

The Debian Policy is:
http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1
---
Each program, utility, and function should have an associated manual
page included in the same package.
---

http://www.debian.org/doc/debian-policy/ch-scope.html
---
In the normative part of this manual, the words must, should and may,
and the adjectives required, recommended and optional, are used to
distinguish the significance of the various guidelines in this policy
document. Packages that do not conform to the guidelines denoted by must
(or required) will generally not be considered acceptable for the Debian
distribution. Non-conformance with guidelines denoted by should (or
recommended) will generally be considered a bug, but will not
necessarily render a package unsuitable for distribution. Guidelines
denoted by may (or optional) are truly optional and adherence is left to
the maintainer's discretion.
---

http://www.debian.org/doc/debian-policy/ch-archive.html#s-main
---
In addition, the packages in main
* must not require a package outside of main for compilation or
execution (thus, the package must not declare a Depends, Recommends,
or Build-Depends relationship on a non-main package)
---

The non-conformance of a should guideline will generally be
considered a bug. I think we have an exceptional case here where the
binaries are Free and in one Debian package but the manpages are
currently Non-free and in a separate Debian package, therefore we can
*not* use Depends.

Ian Jackson's (co-author of Debian Policy) comments:
http://lists.debian.org/debian-devel/2008/02/msg01026.html
---
I think the point of policy is to ensure the manpage exists, not to
require that it be installed.

I think Suggests is the right dependency.  There is nothing wrong with
installing a package without its documentation.
---

cya,
#




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#466922: How to resolve critical situation

2008-03-03 Thread Harshula
Hi Ming,

On Sun, 2008-03-02 at 11:10 -0600, Ming Hua wrote:

 Indirect build dependency.  Scim-uim build-depends on libuim-dev, which
 depends on libm17n-dev, which depends on libm17n-0, which depends on
 m17n-db.

Thanks for the info.

I discussed the m17n intra-dependencies with upstream a few weeks ago:
http://www.m17n.org/mlarchive/m17n-lib/200802/msg00011.html

When I update the m17n-lib Debian source package, I'm planning on
libm17n to *not* depend on m17n-db. The next time I update the other
m17n packages, I'm planning on using upstream's suggestions.

cya,
#




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#466922: How to resolve critical situation

2008-03-03 Thread Harshula
Hi Osamu,

On Mon, 2008-03-03 at 21:07 +0900, Osamu Aoki wrote:

  Dicussion on debian-devel:
  http://lists.debian.org/debian-devel/2008/02/msg00636.html
 
 Quick look tells me Ian (ex-DPL) said:
 
   I think the point of policy is to ensure the manpage exists, not to
   require that it be installed.
   
   I think Suggests is the right dependency.  There is nothing wrong with
   installing a package without its documentation.
 
 This is quite conclusive.

I didn't weight the opinions, but the opinion tally seemed to be:
Depends: 3
Recommmend: 1
Suggest: 1

  I already announced ITH back in November 2007:
  http://lists.debian.org/debian-devel/2007/11/msg00440.html
 
 Good.  Let's do it now.

http://ftp-master.debian.org/new/m17n-docs_1.5.0-1.html

cya,
#




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#466922: How to resolve critical situation

2008-03-03 Thread Harshula
Hi Osamu,

I made a mistake and fortunately Joerg noticed it. The m17n-docs license
contains a 'Cover Text' (hence considered not Free) and does not have
the latex source that would be needed to create the PS and DVI files in
usr/latex/.

I've emailed the m17n developers and asked them whether it is possible
for them to resolve these two issues.

More importantly, how do we resolve your immediate needs? Could we ask
for m17n-db 1.3.4-2 to be yanked from unstable and replaced with
1.3.4-1?

cya,
#




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#466922: How to resolve critical situation

2008-03-02 Thread Harshula
Hi Osamu,

First and foremost I have updated the m17n-docs source package and I've
uploaded it to:
http://sinhala.sourceforge.net/files/m17n/

There is one Lintian error with the manpages that I'm waiting to hear
from upstream about before I decide how to fix it.

On Sun, 2008-03-02 at 23:53 +0900, Osamu Aoki wrote:
 Hi,
 
 This bug 466922 for m17n-db is blocking other packages such as scim-uim
 to build.

Why? What's the relationship between scim-uim and m17n-db?

   I think we should attack this situation in 2 steps.
 
 Let's review situation:
 
 There was bug #465661 for m17n-db claiming binary-without-manpage
 usr/bin/m17n-db.  This was based on policy 12.1 which states:
 
 Each program, utility, and function should have an associated manual
 page included in the same package. 
 
 It is mere should whereas the basis of bug 466922 was policy 2.2.1
 which states:
 
 In addition, the packages in main
   * must not require a package outside of main for compilation or
 execution (thus, the package must not declare a Depends,
 Recommends, or Build-Depends relationship on a non-main
 package),
 
 Yes, this is serious policy bug.
 
 First, we should avoid serious bug if possible even with minor
 shortcoming.  The correct thing to do is:
 
   1. File bug to get unreasonable move to non-free (already done)
   2. Just Suggest m17n-doc for now.  (Once m17n-doc is back in main
   change it to depends if you think that is right thing).  Really, it is
   only policy with should so Suggest may be enough. (at least to me.
   But I may be wrong)

Dicussion on debian-devel:
http://lists.debian.org/debian-devel/2008/02/msg00636.html

 I agree moving m17n-doc to main is right thing.  But the order of action
 should be carefully thought out. Please remove m17n-doc from depends
 now and set suggest.

Since I have updated the m17n-doc source package, would it be better to
upload that, even with the minor Lintian manpage errors?

 Iwai-san, are you still active? Omote-san who seemed to uploaded his
 package, can you comment?  This package seems practically orphaned.
 
 Considering 434044, Harshula should hijack m17n-doc package unless we
 get response from them in a week or so.  I will be happy to see m17n-db
 maintainer taking charge of all related packages.

I already announced ITH back in November 2007:
http://lists.debian.org/debian-devel/2007/11/msg00440.html

 I was quite surprized by the non-free move.  GFDL without invariant
 section seems to be OK to be in main.

I suspect it happened before the 2006 Debian vote on the issue.

 Osamu
 
 PS: The upload to main may need to happen after requesting removal of
 current non-free one. 

What's the procedure for that?

Thanks,
#




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#466922: m17n-db: depends on a non-free package

2008-02-24 Thread Harshula
Hi Michal,

m17n-docs is licensed under the GNU Free Documentation License 1.2 with
*no* Invariant Sections:
--
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.
A copy of the license is included in the section entitled GNU
Free Documentation License.
--

m17n-docs was initially packaged in 2004, before the 2006 Debian vote on
the GFDL. I assume that is the reason why it is in non-free.

In 2006, GFDL (with no Invariant Sections) was recognised to be free:
http://lists.debian.org/debian-devel-announce/2006/03/msg00012.html

Do you agree the correct solution would be to update m17n-docs and move
it from non-free to main?

cya,
#

On Thu, 2008-02-21 at 21:47 +0100, Michal Politowski wrote:
 Package: m17n-db
 Version: 1.3.4-2
 Severity: serious
 Justification: Policy 2.2.1
 
 m17n-db depends on the m17n-docs package which is in non-free




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]