Re: Should lambda-align v2 replace v1 or be its own Debian package?

[Sascha Steinbiss]

Hi Michael,

[...]
> Pursuant to that I split off the v2.0.0 packaging:
> https://salsa.debian.org/med-team/lambda-align2
[...]
> I think this is ready for sponsorship for the NEW queue.
Could you please make sure that we have an ITP for that? I'll take a
look tomorrow then, try to address Hannes' comments and get it uploaded
if everything works out.

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Re: picard-tools: autopkgtest regression

[Olivier Sallou]

- Andreas Tille  a écrit :
> On Thu, Jan 17, 2019 at 06:49:14PM +0100, Olivier Sallou wrote:
> > 
> > 
> > I tested against a local build of the package though local build (which
> > runs tests) works fine. (both are run on the same machine)!
> > 
> > autopkgtest does not keep the tempory directory used, so I cannot look
> > at test report (testng) to find failing tests.
> 
> Why not uncommenting line
> 
>  trap "rm -rf $ADTTMP" 0 INT QUIT ABRT PIPE TERM

I had not seen this, thanks, will try!
> 
> and may be also add
> 
>  set -x
> 
> for debugging?
> 
> Kind regards
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de
> 

Re: DCMTK #913304

[Julien Lamy]

Le 17/01/2019 à 22:14, Gregory Sharp a écrit :
> 
> Hi,
> 
> I have been investigating #913304 [1], which causes plastimatch tests to fail.
> (Also it makes dcmdump not working in sid.)   I think the problem can be
> solved by:
> 
> sed -e 's/CMAKE_INSTALL_DATADIC/DCMTK_INSTALL_DATDIC/'
> 
> to debian/patches/03_datadic_install.patch.  
> 
> If anyone familiar with this package can verify my idea, I would be super
> thankful.  Otherwise I will test myself, maybe next week.
> 
> Thank you,
> Greg
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913304
> 

I think that Gert's idea in one of his latest commits [1] was actually
to be able to have several dictionaries installed, one for each
SOVERSION of libdcmtk. This makes sense since the symbols in the
dictionaries are part of DCMTK's API and will change from one version to
another. However, this requires the user to target the correct version
of DCMTK by setting DCMDICTPATH. I've had a similar problem with Odil
and solved it by using whatever dictionary I could find [2].

Gert, what's your take on this? Bug or feature?

[1] https://salsa.debian.org/med-team/dcmtk/commit/ce7924e
[2]
https://salsa.debian.org/med-team/odil/commit/ba63ae4#8756c63497c8dc39f7773438edf53b220c773f67_5_6

Cheers,
-- 
Julien



signature.asc
Description: OpenPGP digital signature

Re: Hmmer2 fork / enhancements (Was: Is my post making it to the mailing list?)

[Joshua Marshall]

I'm aware.  I only really have time to touch this on weekends, sorry.
Right now, I'm working on changes with squid to make things easier on
Arch.  This weekend is a tad busy, so I'll likely get time to touch this
again on the 26th.

I'm thinking to hold off on the upload until you or I run the build in test
suite to make sure no surprises happened.

On Thu, Jan 17, 2019 at 2:25 PM Andreas Tille  wrote:

> Hi again,
>
> I just want to repeat that I will not upload until you become more
> verbose what exactly should be tested.  I understood your last mail that
> I should not upload before something is tested - but what exactly?
>
> Kind regards
>
> Andreas.
>
> On Mon, Jan 14, 2019 at 03:27:13PM +0100, Andreas Tille wrote:
> > On Mon, Jan 14, 2019 at 06:41:32AM -0500, jrmarsha wrote:
> > > There is no question in that message.
> > >
> > > On 1/13/19 11:35 PM, Andreas Tille wrote:
> > > > On Sun, Jan 13, 2019 at 09:22:13PM -0500, jrmarsha wrote:
> > > > > I've thought I've answered questions a few times.  Are messages
> getting
> > > > > dropped?  I didn't get the one just before from Steffen.
> > > > I did not received any answer to
> > > >
> > > > https://lists.debian.org/debian-med/2019/01/msg00046.html
> >
> > Syntactically you are correct but I would have expected some response to
> > "I'm not fully sure what you want me to test."
> >
> > I assumed you wanted me to test something before uploading.  If this
> > is not the case I can upload the current packaging status and users
> > should test later (beyond the autopkgtest).
> >
> > Is this OK?
> >
> > Kind regards
> >
> >   Andreas.
> >
> > --
> > http://fam-tille.de
> >
> >
>
> --
> http://fam-tille.de
>
>

Re: Hmmer2 fork / enhancements (Was: Is my post making it to the mailing list?)

[Andreas Tille]

Hi again,

I just want to repeat that I will not upload until you become more
verbose what exactly should be tested.  I understood your last mail that
I should not upload before something is tested - but what exactly?

Kind regards

Andreas.

On Mon, Jan 14, 2019 at 03:27:13PM +0100, Andreas Tille wrote:
> On Mon, Jan 14, 2019 at 06:41:32AM -0500, jrmarsha wrote:
> > There is no question in that message.
> > 
> > On 1/13/19 11:35 PM, Andreas Tille wrote:
> > > On Sun, Jan 13, 2019 at 09:22:13PM -0500, jrmarsha wrote:
> > > > I've thought I've answered questions a few times.  Are messages getting
> > > > dropped?  I didn't get the one just before from Steffen.
> > > I did not received any answer to
> > > 
> > > https://lists.debian.org/debian-med/2019/01/msg00046.html
> 
> Syntactically you are correct but I would have expected some response to
> "I'm not fully sure what you want me to test."
> 
> I assumed you wanted me to test something before uploading.  If this
> is not the case I can upload the current packaging status and users
> should test later (beyond the autopkgtest).
> 
> Is this OK?
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: picard-tools: autopkgtest regression

[Andreas Tille]

On Thu, Jan 17, 2019 at 06:49:14PM +0100, Olivier Sallou wrote:
> 
> 
> I tested against a local build of the package though local build (which
> runs tests) works fine. (both are run on the same machine)!
> 
> autopkgtest does not keep the tempory directory used, so I cannot look
> at test report (testng) to find failing tests.

Why not uncommenting line

 trap "rm -rf $ADTTMP" 0 INT QUIT ABRT PIPE TERM

and may be also add

 set -x

for debugging?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: bcbio - kind of ready, but dependencies gffutils and pybedtools are no longer distributed

[Steffen Möller]

I now updated pybedtools to 0.8.0.

bcbio also builds with that newer version.

4 tests of the many pybedtools fail, one of them about internet access, 
but also one that looks like an error. Could someone please have a look? 
I'll upload with tests disabled in the meantime.


Best,

Steffen

On 17.01.19 16:59, Michael Crusoe wrote:

Glad to hear about the BCBIO progress!

I removed those packages, they were only removed due to lack of use, 
so it is not problem if you bring them back.


În joi, 17 ian. 2019 la 17:53, Steffen Möller > a scris:


Hello,

I just finished what started at 2018 Sprint, i.e. the packaging of
bcbio. Their december release builds without a patch and autotests
with
Python 3 are fine. I just uploaded 1.1.2 to salsa - please have a
look.
Now, running pbuilder I ran into missing packages for

https://tracker.debian.org/pkg/python-pybedtools
https://tracker.debian.org/pkg/python-gffutils

which in the meantime have been removed from the distribution. The
source tree of bcbio makes strong direct use of them both. Can we
have
them back? There was no technical reason for these packages to
disappear, right?

Best,

Steffen




--
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project 


Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670 


m...@commonwl.org 
+1 480 627 9108 / +370 653 11125

Re: picard-tools: autopkgtest regression

[Olivier Sallou]

On 1/17/19 1:24 PM, Paul Gevers wrote:
> Hi Olivier,
>
> On 17-01-2019 12:12, Olivier Sallou wrote:
>> I tested in buster with updated libbarclay-java (2.1.0-3 pushed today to
>> allow migration to testing) and could rebuild picard-tools from source
>> (with tests) with no issue.
>>
>>
>> I tried again with libbarclay-java 2.1.0-2 and faced no issue either.
> The autopkgtest also fails in unstable. If you are only testing builds,
> and not actually running autopkgtest, than it may be that you have a
> build dependency that you miss during the tests, because you didn't add
> it to the test dependencies.

I fixed picard-tools (git only) to fix the classpath in jar manifest and
bin PicardCommandLine.


running autopkgtest with test removes the ClassNotFound error, however
it results in failure of 2 tests.

I tested against a local build of the package though local build (which
runs tests) works fine. (both are run on the same machine)!

autopkgtest does not keep the tempory directory used, so I cannot look
at test report (testng) to find failing tests. The autopkgtest report is
too verbose and I cannot find failing tests in this log file.


I don't understand why some tests fail with autopkgtest and not with gbp
buildpackage on the same server.


>
> Paul
>
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



signature.asc
Description: OpenPGP digital signature

Re: bcbio - kind of ready, but dependencies gffutils and pybedtools are no longer distributed

[Michael Crusoe]

Glad to hear about the BCBIO progress!

I removed those packages, they were only removed due to lack of use, so it
is not problem if you bring them back.

În joi, 17 ian. 2019 la 17:53, Steffen Möller  a
scris:

> Hello,
>
> I just finished what started at 2018 Sprint, i.e. the packaging of
> bcbio. Their december release builds without a patch and autotests with
> Python 3 are fine. I just uploaded 1.1.2 to salsa - please have a look.
> Now, running pbuilder I ran into missing packages for
>
> https://tracker.debian.org/pkg/python-pybedtools
> https://tracker.debian.org/pkg/python-gffutils
>
> which in the meantime have been removed from the distribution. The
> source tree of bcbio makes strong direct use of them both. Can we have
> them back? There was no technical reason for these packages to
> disappear, right?
>
> Best,
>
> Steffen
>
>
>

-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670

m...@commonwl.org
+1 480 627 9108 / +370 653 11125

bcbio - kind of ready, but dependencies gffutils and pybedtools are no longer distributed

[Steffen Möller]

Hello,

I just finished what started at 2018 Sprint, i.e. the packaging of 
bcbio. Their december release builds without a patch and autotests with 
Python 3 are fine. I just uploaded 1.1.2 to salsa - please have a look. 
Now, running pbuilder I ran into missing packages for


https://tracker.debian.org/pkg/python-pybedtools
https://tracker.debian.org/pkg/python-gffutils

which in the meantime have been removed from the distribution. The 
source tree of bcbio makes strong direct use of them both. Can we have 
them back? There was no technical reason for these packages to 
disappear, right?


Best,

Steffen

Re: picard-tools: autopkgtest regression

[Olivier Sallou]

On 1/17/19 1:24 PM, Paul Gevers wrote:
> Hi Olivier,
>
> On 17-01-2019 12:12, Olivier Sallou wrote:
>> I tested in buster with updated libbarclay-java (2.1.0-3 pushed today to
>> allow migration to testing) and could rebuild picard-tools from source
>> (with tests) with no issue.
>>
>>
>> I tried again with libbarclay-java 2.1.0-2 and faced no issue either.
> The autopkgtest also fails in unstable. If you are only testing builds,
> and not actually running autopkgtest, than it may be that you have a
> build dependency that you miss during the tests, because you didn't add
> it to the test dependencies.

ok, I think I found the issue.


the manifest  of jar file does not include defined classpath. As a
result, called binary in scripts does not find the dependencies at runtime.

At build/test time, classpath is correctly defined.

I gonna have a look.

>
> Paul
>
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



signature.asc
Description: OpenPGP digital signature

Re: how to make https://salsa.debian.org/med-team/libdeflate public?

[Andreas Tille]

On Thu, Jan 17, 2019 at 12:27:22PM +0200, Michael Crusoe wrote:
> În mar., 15 ian. 2019 la 20:40, Andreas Tille  a scris:
> 
> > if you used the inject-into-salsa-git script and the result was not
> > public that script is most probably broken.  It happened to me in the
> > beginning and I needed some testing until it worked.
> 
> I think this package dates before my usage of inject-into -salsa-git ?

I did not checked.  Just mentioned how I ended up with non-public
repositories once.

> > As I told you in PM something in your last commit has broken new
> > commits - may be that's another consequence.  (Sorry, no time /
> > motivation to fix this before I need to inject some new code.)
> 
> I believe I have fixed those issues in my latest commit; guess we need a
> testing framework :-P

May be that's a good idea.  I'll check with my next new package.

Thanks in any case

  Andreas.

-- 
http://fam-tille.de

Re: picard-tools: autopkgtest regression

[Paul Gevers]

Hi Olivier,

On 17-01-2019 12:12, Olivier Sallou wrote:
> I tested in buster with updated libbarclay-java (2.1.0-3 pushed today to
> allow migration to testing) and could rebuild picard-tools from source
> (with tests) with no issue.
> 
> 
> I tried again with libbarclay-java 2.1.0-2 and faced no issue either.

The autopkgtest also fails in unstable. If you are only testing builds,
and not actually running autopkgtest, than it may be that you have a
build dependency that you miss during the tests, because you didn't add
it to the test dependencies.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Request for sponsorship: python-mypy-extensions

[Andreas Tille]

Uploaded.  Thanks for your work on this, Andreas.

On Thu, Jan 17, 2019 at 12:39:43PM +0200, Michael Crusoe wrote:
> https://salsa.debian.org/med-team/python-mypy-extensions
> 
> This Python module has split off from the mypy sources upstream, so now it
> needs splitting out of python3-mypy into its own package.
> 
> This package is required for the latest version of mypy, v0.660
> 
> gbp clone g...@salsa.debian.org:med-team/python-mypy-extensions.git
> 
> Thanks!
> -- 
> Michael R. Crusoe
> Co-founder & Lead, Common Workflow Language project
> 
> Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
> https://orcid.org/-0002-2961-9670
> 
> m...@commonwl.org

-- 
http://fam-tille.de

Re: picard-tools: autopkgtest regression

[Olivier Sallou]

On 1/17/19 10:07 AM, Paul Gevers wrote:
> Hi Olivier,
>
> On 17-01-2019 09:38, Olivier Sallou wrote:
>> On 1/17/19 9:25 AM, Paul Gevers wrote:
>>> autopkgtest [04:38:35]: test run-unit-test: [---
>>> Error: Unable to initialize main class picard.cmdline.PicardCommandLine
>>> Caused by: java.lang.NoClassDefFoundError:
>>> org/broadinstitute/barclay/argparser/CommandLineProgramProperties
>>> autopkgtest [04:38:36]: test run-unit-test: ---]
>> picard-tools depends on libbarclay-java. I see that it is has been
>> removed from testing, this is why it fails. I wonder however
>>
>> Previous picard-tools in testing did not depend on this library.
>> Migration of picard-tools is currently blocked by this libbarclay-java
>> bug (#906973)
> libbarclay-java is installed in the test, so that can't explain the failure:
> Setting up libbarclay-java (2.1.0-2) ...

I tested in buster with updated libbarclay-java (2.1.0-3 pushed today to
allow migration to testing) and could rebuild picard-tools from source
(with tests) with no issue.


I tried again with libbarclay-java 2.1.0-2 and faced no issue either.

Olivier



>
> Paul
>
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438




signature.asc
Description: OpenPGP digital signature

Request for sponsorship: python-mypy-extensions

[Michael Crusoe]

https://salsa.debian.org/med-team/python-mypy-extensions

This Python module has split off from the mypy sources upstream, so now it
needs splitting out of python3-mypy into its own package.

This package is required for the latest version of mypy, v0.660

gbp clone g...@salsa.debian.org:med-team/python-mypy-extensions.git

Thanks!
-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670

m...@commonwl.org

Re: how to make https://salsa.debian.org/med-team/libdeflate public?

[Michael Crusoe]

În mar., 15 ian. 2019 la 20:40, Andreas Tille  a scris:

> On Tue, Jan 15, 2019 at 07:02:34PM +0200, Michael Crusoe wrote:
> > I think I lack the permissions
>
> if you used the inject-into-salsa-git script and the result was not
> public that script is most probably broken.  It happened to me in the
> beginning and I needed some testing until it worked.
>

I think this package dates before my usage of inject-into -salsa-git ?


>
> As I told you in PM something in your last commit has broken new
> commits - may be that's another consequence.  (Sorry, no time /
> motivation to fix this before I need to inject some new code.)
>

I believe I have fixed those issues in my latest commit; guess we need a
testing framework :-P


> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>


-- 
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project

Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670

m...@commonwl.org
+1 480 627 9108 / +370 653 11125

Bug#919570: ITP: python-mypy-extensions -- Experimental type system extensions for mypy typechecker (Python 3)

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: python-mypy-extensions
  Version : 0.4.1
  Upstream Author : Jukka Lehtosalo and contributors
* URL : https://github.com/python/mypy_extensions/
* License : Expat
  Programming Lang: Python
  Description : Experimental type system extensions for mypy typechecker 
(Python 3)

(Include the long description here.
 Add type annotations to your Python programs, and use mypy to type check them.
 Mypy is essentially a Python linter on steroids, and it can catch many
 programming errors by analyzing your program, without actually having to run
 it. Mypy has a powerful type system with features such as type inference,
 gradual typing, generics and union types.
 .
 The "mypy_extensions" module defines experimental extensions to the
 standard "typing" module that are supported by the mypy typechecker.
 .
 This package provides the modules for Python 3.

This python module was previously part of the python3-mypy binary package from
the mypy source package as it came from the same PyPI source distribution. Now
it has been split into its own sdist/GitHub repo as of mypy v 0.660, so this
separate package is needed.

As with mypy, python-mypy-extensions will be team maintained by Debian Med.

Re: debianmed sprint, leader approval for reimbursments

[Andreas Tille]

On Thu, Jan 17, 2019 at 09:27:44AM +0100, olivier sallou wrote:
> Hi,
> Debian leader has approved reimbursment request for Debianmed sprint for
> DDs and outreachy students.

Great. Thanks a lot for organising and for sure also for leader

 Andreas.

-- 
http://fam-tille.de

Re: picard-tools: autopkgtest regression

[Paul Gevers]

Hi Olivier,

On 17-01-2019 09:38, Olivier Sallou wrote:
> On 1/17/19 9:25 AM, Paul Gevers wrote:
>> autopkgtest [04:38:35]: test run-unit-test: [---
>> Error: Unable to initialize main class picard.cmdline.PicardCommandLine
>> Caused by: java.lang.NoClassDefFoundError:
>> org/broadinstitute/barclay/argparser/CommandLineProgramProperties
>> autopkgtest [04:38:36]: test run-unit-test: ---]

> picard-tools depends on libbarclay-java. I see that it is has been
> removed from testing, this is why it fails. I wonder however
> 
> Previous picard-tools in testing did not depend on this library.
> Migration of picard-tools is currently blocked by this libbarclay-java
> bug (#906973)

libbarclay-java is installed in the test, so that can't explain the failure:
Setting up libbarclay-java (2.1.0-2) ...

Paul



signature.asc
Description: OpenPGP digital signature

Re: picard-tools: autopkgtest regression

[Olivier Sallou]

On 1/17/19 9:25 AM, Paul Gevers wrote:
> Source: picard-tools
> Version: 2.18.23+dfsg-1
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
>
> Dear maintainers,
>
> With a recent upload of picard-tools the autopkgtest of picard-tools
> fails in testing when that autopkgtest is run with the binary packages
> of picard-tools from unstable. It passes when run with only packages
> from testing. In tabular form:
>passfail
> picard-tools   from testing2.18.23+dfsg-1
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it? If needed, please
> change the bug's severity.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [0] You can see what packages were added from the second line of the log
> file quoted below. The migration software adds source package from
> unstable to the list if they are needed to install packages from
> picard-tools/2.18.23+dfsg-1. I.e. due to versioned dependencies or
> breaks/conflicts.
> [1] https://qa.debian.org/excuses.php?package=picard-tools
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/picard-tools/1717365/log.gz
>
> autopkgtest [04:38:35]: test run-unit-test: [---
> Error: Unable to initialize main class picard.cmdline.PicardCommandLine
> Caused by: java.lang.NoClassDefFoundError:
> org/broadinstitute/barclay/argparser/CommandLineProgramProperties
> autopkgtest [04:38:36]: test run-unit-test: ---]

Hi,

picard-tools depends on libbarclay-java. I see that it is has been
removed from testing, this is why it fails. I wonder however

Previous picard-tools in testing did not depend on this library.
Migration of picard-tools is currently blocked by this libbarclay-java
bug (#906973)


Olivier

>
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



signature.asc
Description: OpenPGP digital signature

debianmed sprint, leader approval for reimbursments

[olivier sallou]

Hi,
Debian leader has approved reimbursment request for Debianmed sprint for
DDs and outreachy students.


Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438