Bug#800018: s3cmd: sync leaves empty temp file after permission denied error

[Matt Domsch]

https://github.com/s3tools/s3cmd/issues/636 filed to track in upstream's
tracker.

On Fri, Sep 25, 2015 at 8:09 AM, Conrad Hughes  wrote:

> Hi Gianfranco,
>
> Thanks again for such a rapid turnaround!  So 1.6.0-1 returns to the
> behaviour of 1.5.0~rc1-2: it can run the whole sync despite the 403
> errors, but it still leaves an empty temporary file for every failure..
>
> Regards,
> Conrad
>
>

Bug#781767: Makes it unusable for my buckets too

[Matt Domsch]

Buckets with dots is the AWS recommended method, and is required for all
regions except for us-east-1.  It becomes usable if you use
--no-check-certificate or --no-ssl but that's bad practice too.  So in
practice it is essentially unusable.

On Tue, Jun 16, 2015 at 9:55 AM, Rodrigo Campos rodr...@sdfg.com.ar wrote:

 On Sat, Jun 13, 2015 at 07:24:15AM +, Gianfranco Costamagna wrote:
  Control: severity -1 grave
  Control: found -1 1.5.0~rc1-2
  Control: fixed -1 1.5.2-1
 
  thanks
 
 
  I'm setting the correct severity, since the jessie package is completely
 unusable.

 Well, it's not completely unusable. It is only with buckets with dots in
 their
 name, IIUC. This might be important enough to consider unusable, but there
 is
 subtle difference in theory between not being usable at all and being
 usable in
 some cases. Although, in practice, might be totally unusable (don't know
 how to
 estimate this and IMHO it is unusable)





 Thanks a lot,
 Rodrigo

Bug#781767: Makes it unusable for my buckets too

[Matt Domsch]

Python upstream included the ssl cert checks. Jessie picked up the new
python upstream release. That is all well and good. The right thing to do
is to get s3cmd updated.
On Jun 13, 2015 3:21 AM, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it wrote:

 Hi all,

 I opened a jessie-p-u request here [1]

 I tried to explain (sum this conversation) in the best way I could, please
 read and correct if I wrote anything wrong there.


 Maybe something about this can be fixed with a python upload?
 (just wondering how bad might be reverting the check in a python jessie-pu)

 Matt do you know the python release introducing the problem?

 [1] https://bugs.debian.org/788607




 thanks in advance,

 Gianfranco

Bug#781767: Makes it unusable for my buckets too

[Matt Domsch]

My preference is the backport of 1.5.2. That picks up signature v4 support
which allows Frankfurt and China regions too.
On Jun 12, 2015 4:02 AM, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it wrote:

 Hi Rodrigo and Matt,

 I tried to apply the upstream commit to 1.5.0~rc1-2 and it doesn't apply
 cleanly.

 I see two/three possible solutions:
 1) upgrade to stretch (just almost jocking) or apt-pinning s3cmd from there
 2) change the upstream commit to apply on top of 1.5.0~rc1 version
 3) backport the 1.5.2 to jessie-backports.


 It is up to you,
 Rodrigo you can do 1, Matt you can do 2, and I can do 3.

 I would prefer a stable-release-update, but backporting the new 1.5.2,
 might be better because some new features have been added

 In the meanwhile you have your backport ready there

 http://debomatic-amd64.debian.net/distribution#jessie-backports/s3cmd/1.5.2-2~bpo8+1/buildlog
 :)

 cheers,

 G.





 Il Venerdì 12 Giugno 2015 1:36, Rodrigo Campos rodr...@sdfg.com.ar ha
 scritto:
 On Thu, Jun 11, 2015 at 04:42:15PM -0500, Matt Domsch wrote:
  The copy in jesse's repository is 1.5.0~rc1-2 which is not v1.5.2 where
 the fix
  was committed.  I see the same failure if I simply apt-get install s3cmd
 on a
  new jesse install.  v1.5.2 is in experimental and unstable or can be
 downloaded
  from https://github.com/s3tools/s3cmd.

 Exactly. And my point is to fix this in jessie, if possible.

 As I said in my first mail, it renders the package unusable to me (and all
 people who is using dots in the buckets name). I upgraded to jessie and
 because
 of this bug some scripts are now broken.






 Thanks a lot,
 Rodrigo

Bug#781767: Makes it unusable for my buckets too

[Matt Domsch]

The breakage predates you Gianfranco.  Not your fault.  Python got updated
in Jesse right before it released.  That python added in https ssl
certificate checking for all HTTPSConnection() usage, per the RFC regarding
how to check the certificate.  The RFC explicitly disallows
bucket.with.dot.s3.amazonaws.com DNS names from matching *.s3.amazonaws.com
wildcard certificates.  But that's exactly what S3 uses.  So we had to add
a custom certificate checker into v1.5.2 to fix it correctly.  We were past
freeze for updating packages in jesse at that point, so we couldn't get the
fix into the main release.  (in Fedora, we can easily issue updates into an
updates repo, so I didn't think much about it.; apparently that's harder in
Debian to release updates).

On Fri, Jun 12, 2015 at 4:05 PM, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it wrote:

 Hi Matt,

 what do you mean by broke s3cmd? you mean the current jessie version is
 completely unusable?

 I honestly never tried it, my first release (used and packaged) as you
 know has been 1.5.2, and I'm using it since some months :)

 If the jessie version is completely broken I need to talk with release
 team, we might be able to make 1.5.2 go in jessie p-u (and eventually in
 the next point release)
 or drop it from the archive completely.

 I would have not released jessie with that package if I had been aware of
 its usefulness.
 (I would have updated it before if had the need of it, but I just didn't
 know about its existance before I had used it :) )


 cheers!

 G.


 Il Venerdì 12 Giugno 2015 19:39, Matt Domsch m...@domsch.com ha scritto:



 By the time we knew Jesse's python SSL library change (actual cert
 validation) broke s3cmd it was too late to update the s3cmd package to a
 new enough version to fix it. And no I have not done a 1.5.0~rc1-X that is
 really just 1.5.2. But that is what is needed.
 On Jun 12, 2015 10:55 AM, Gianfranco Costamagna 
 costamagnagianfra...@yahoo.it wrote:

 Control: tags -1 -patch
 thanks
 
 Not any particular problem, just that the jessie version seems totally
 
 useless...
 
 
 not for me :)
 this bug affects only part of people, not all of them ;)
 
 
 Anyway, the backport is still useful for people who want to try new
 features, and
 if you really want jessie to be fixed, you are encouraged to download the
 source and make the patch apply there
 
 
 
 I fully agree, but I do not have time to look at it right now :(
 
 I'll be happy to ask an spu and upload the package if a patch is provided!
 
 cheers,
 
 G.
 

Bug#781767: Makes it unusable for my buckets too

[Matt Domsch]

By the time we knew Jesse's python SSL library change (actual cert
validation) broke s3cmd it was too late to update the s3cmd package to a
new enough version to fix it. And no I have not done a 1.5.0~rc1-X that is
really just 1.5.2. But that is what is needed.
On Jun 12, 2015 10:55 AM, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it wrote:

 Control: tags -1 -patch
 thanks

 Not any particular problem, just that the jessie version seems totally

 useless...


 not for me :)
 this bug affects only part of people, not all of them ;)


 Anyway, the backport is still useful for people who want to try new
 features, and
 if you really want jessie to be fixed, you are encouraged to download the
 source and make the patch apply there



 I fully agree, but I do not have time to look at it right now :(

 I'll be happy to ask an spu and upload the package if a patch is provided!

 cheers,

 G.

Bug#781767: Makes it unusable for my buckets too

[Matt Domsch]

The copy in jesse's repository is 1.5.0~rc1-2 which is not v1.5.2 where the
fix was committed.  I see the same failure if I simply apt-get install
s3cmd on a new jesse install.  v1.5.2 is in experimental and unstable or
can be downloaded from https://github.com/s3tools/s3cmd.



On Thu, Jun 11, 2015 at 2:30 PM, Rodrigo Campos rodr...@sdfg.com.ar wrote:

 On Thu, Jun 11, 2015 at 01:38:01PM -0500, Matt Domsch wrote:
  Please run a failing case with --debug and report results.

 I'm not sure why you need this, as it's trivial to reproduce and the
 original
 report says which commit should fix it. But here it goes anyways...

   v1.5.2 should not
  fail on Debian any longer.

 But that is not on jessie :)




 Thanks a lot,
 Rodrigo

Bug#781767: Makes it unusable for my buckets too

[Matt Domsch]

Please run a failing case with --debug and report results.  v1.5.2 should
not fail on Debian any longer.

On Thu, Jun 11, 2015 at 1:08 PM, Rodrigo Campos rodr...@sdfg.com.ar wrote:

 Hi,

 Any news on this ? I've upgraded to jessie and scripts using s3cmd broke
 because
 of this bug. It renders the package unusable to me (and all using dots in
 the
 buckets name).

 As a workaround, just in case, I've used s3cmd from a python virtual env
 using
 the last release. Probably the package from testing fixes it too.


 If I can help with testing or something, please let me know





 Thanks a lot,
 Rodrigo

Bug#781767:

[Matt Domsch]

fixed 780584 1.5.2-1
thanks
--
s3cmd 1.5.2 is pending review, and includes this fix.
Bug 780584 has the ITA, and needs a sponsor for completing the submission.

Bug#780584: RFS: s3cmd/1.5.2-1 ITA

[Matt Domsch]

Harlan, thanks for the review.

I'm happy to have any of my trivial contributions under debian/ be GPL-2+.

I removed a patch from debian/patches that fixed up manpage typos.  The
manpage is automatically generated.  I'll look into updating the generator
to escape the errors for a future release.

Upstream changelog is extremely outdated since moving from svn to git
several years ago.  I wouldn't worry about including it.  I dropped it from
the RPM package.

I changed the watch file from SF to github, but didn't think about the
signature then being invalid.  1.5.0-rc package has the SF-pointing watch
file.  Would be trivial to switch it back to that copy.

Thanks,
Matt

On Tue, Mar 17, 2015 at 5:34 PM, Harlan Lieberman-Berg hlieber...@setec.io
wrote:

 Hello Gianfranco!

 Thank you for your work on the s3cmd package.  I'm not able to sponsor
 your package at this time, but I've done a review for you to help fix up
 a couple of nitpicks while you wait.

 The most concerning issue to me is the change in d/copyright from GPL-2
 to GPL-2+ for the files under debian/.  Matching them to upstream is
 best practice, to be sure, but to do so needs the permission of the
 authors of all the files underneath there - especially, it looks like,
 Mikhail Gusarov.  It's not clear to me whether Matt Domsch's permission
 might also be needed; it certainly couldn't hurt, though.

 The man page has a couple of errors as well - groff is picking up some
 text and trying to apply it as a macro.  There are also unescaped
 -'s that need to be escaped so they are not mistaken as hyphens
 instead of minuses.  There's also a spelling error in the man file.  All
 of these are upstream problems - probably with the tool they are using
 to create the manpage itself - but should be fixed if possible.

 Other than that, the remaining tweaks are minor.  You should install the
 upstream changelog since it's provided.  Upstream does provide GPG
 signatures of the downloads, so you should verify them if possible - the
 uscan(1) manpage has details about how to do so.  That will require
 changing the watch file from github to sourceforge.

 Thanks again for your work on s3cmd, and on Debian!  If you have
 questions, please reach out to me.

 Sincerely,

 --
 Harlan Lieberman-Berg
 ~hlieberman

 --
 To unsubscribe, send mail to 780584-unsubscr...@bugs.debian.org.

Bug#674916: ITP

[Matt Domsch]

Thank you Gianfranco.  I gladly welcome your assistance and hope you find
s3cmd an easy package to maintain.

On Mon, Mar 16, 2015 at 5:58 AM, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it wrote:

 Hi Mikhail, Matt et all.

 I would like to adopt s3cmd.

 I have updated the package to the latest upstream release and fixed many
 packaging issues starting from Matt's version.

 I put Matt and myself as Uploaders, and PAPT as maintainer.


 I also opened an RFS (#780584) in case you are too busy to review it :)

 cheers,

 Gianfranco

 --
 To unsubscribe, send mail to 674916-unsubscr...@bugs.debian.org.

Bug#674916: s3cmd 1.5.2

[Matt Domsch]

As upstream maintainer for s3cmd, I would very much like to see newer
version 1.5.2 packaged.  I took the liberty of making updates to the debian
packaging on aiolith and have placed it here:

https://domsch.com/s3cmd/debian/

There you will find a debuild build, and patch for debian/.

Sincerely,
Matt Domsch
Upstream maintainer, s3cmd

Bug#439462: linux-2.6: pci ordering issue

[Matt Domsch]

On Fri, Dec 26, 2008 at 01:21:45AM +0100, Moritz Muehlenhoff wrote:
 On Sat, Aug 25, 2007 at 01:22:37AM -0700, Matt Taggart wrote:
  Package: linux-2.6
  Version: 2.6.18.dfsg.1-13etch1
  
  Last September Matt Domsch matt_dom...@dell.com reported a problem where, 
  due to the difference in the way the 2.4 and 2.6 kernels walk the PCI bus, 
  on some systems drivers (mainly NIC drivers) were discovering and naming 
  devices in different orders from 2.4 to 2.6. The problem, potential 
  solutions, and proposed patch are at
  
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif
  f;h=6b4b78fed47e7380dfe9280b154e8b9bfcd4c86c
[snip]
  I am filing this bug against a specific version of linux-2.6, but it 
  affects all older 2.6 kernels and all newer 2.6 kernels up to the point the 
  above patches made it into a debian kernel (the first patch was in upstream 
  2.6.19 at least).
 
 Matt,
 this patch was never backported to the 2.6.18 kernel.
 Since most systems should be upgraded to Etch by now I think we should just
 close this bug. Do you agree?
 
 (Also all NICs are covered the persistent-net-rules udev rule)

yes, I agree.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com  www.dell.com/linux



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

Bug#351056: FIX for #351056, apt always reinstalling packages because identical versions are not merged in the cache

[Matt Domsch]

On Fri, Aug 03, 2007 at 09:14:11PM +0200, Magnus Holmgren wrote:
 tags 351056 + patch
 thanks
 
 This patch should fix the bug. Previously, pkgCacheGenerator::MergeList() 
 would stop when it found a Version less than or equal to the one being added, 
 but if the hashes didn't match at first, it would always add a new Version, 
 even if there was a Version with a matching Hash. My patch loops until a 
 matching Version and Hash is found *or* the new version is greater than the 
 remaining old ones, which makes the second loop unnecessary.

FYI, I am seeing this problem as well, but this patch, while it
applies cleanly, does not resolve it for me.  I've tried after apt-get
clean and after removing the /var/cache/apt/*.bin files, and I've
tried applying only the first patch hunk, with no success.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com  www.dell.com/linux



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

Bug#439462: potential solutions

[Matt Domsch]

Matt T, thanks for pointing this out.

The solution being employed by other distributions is based on udev,
and twofold.

1) include a udev rule to create persistent ethernet device naming.
   The first time a new MAC address is detected, add a rule to a udev
   rule file(e.g. 70-persistent-net-devices.rules) with the new
   entry.  If such exist, then it renames devices based on their MAC
   address to the name specified in the rule.  Udev 013 and higher can
   rename ethernet devices themselves via such rules.

2) include a udev rule and new application I wrote, biosdevname
   (http://linux.dell.com/files/biosdevname) which is called after
   70-persistent-net-devices.rules (so existing persistent names
   remain), but before other net-device-naming rules.  biosdevname
   uses various explicit data from SMBIOS, or heuristics otherwise, to
   name net devices based on what BIOS expects them to be named.

Both are necessary to solve this properly.  For dist-upgrades, you
want to be sure your 70-persistent-net-devices.rules file exists, so
the kernel name given (correct or incorrect from your POV) doesn't
matter - the only thing that matters is what is in the rules file.
Absent the rules file, you want biosdevname invoked via udev rules.
Absent that, fall back to whatever your normal net naming rules would
be, either udev or kernel-provided.

I'm actively working with Fedora/RH and OpenSuSE/SLE to implement the
above strategy.  I would expect Debian and derivatives to do
likewise.  This is being actively discussed on the
[EMAIL PROTECTED] mailing list, the home of udev.

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com  www.dell.com/linux


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

Bug#357884: efibootmgr: update to latest upstream release 0.5.3

[Matt Domsch]

Package: efibootmgr
Severity: normal

Please upgrade efibootmgr in etch to latest upstream release.  This
enables efibootmgr to work properly on 32-bit EFI systems, among other fixes.
Home page: http://linux.dell.com/efibootmgr/

Changelog since last Debian release (0.5.1):

* Wed Nov 9 2005 Matt Domsch [EMAIL PROTECTED]
- released v0.5.2.2 as v0.5.3, no changes
  
* Thu Aug 11 2005 Matt Domsch [EMAIL PROTECTED]
- applied patch from Rogerio Timmers which adds a new option -@ file,
  which takes extra variable parameters from file, or - from stdin.
  This lets you pass binary (non-unicode, non-ascii) formatted options
  to your bootloader.
- cleaned up Rogerio's patch some.
- moved definition of _FILE_OFFSET_BITS=64 into Makefile and out of
the individual .c files.  This fixes a bug reported by Red Flag, where
variable data was getting incorrectly set with a 32-bit copy of
efibootmgr on a 32-bit kernel.

- made efi_variable_t.DataSize be an unsigned long to match the
kernel.  This lets a 32-bit copy of efibootmgr run on a 32-bit kernel.
This means you've got to have a 32-bit efibootmgr on a 32-bit kernel,
and a 64-bit efibootmgr on a 64-bit kernel, but since efi_status_t is
also a long, this was really going to be the case anyway.

- valgrind caught the app exiting without freeing some malloc'd
  structures, fix that.
- v0.5.2.2 released for testing 


* Fri May 20 2005 Matt Domsch [EMAIL PROTECTED]
- applied patch from Andreas Schwab to properly parse PCI
  domain:bus:device.fn info in netboot entries.  Fixed up return value
  when creating network boot entries for nonexistant devices, so the
  creation now fails, rather than succeeding with incorrect data.
- v0.5.2 released



-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#311130: Fw: initial debian packages of dkms

[Matt Domsch]

I built some debian packages of DKMS.  It's my first time building
debs, so give it a try and be nice.

Some things I noted:
* Debian doesn't leave a prebuilt kernel tree sitting around.  This
means you'll have to manually install kernel-source-${version} and
then untar it in /usr/src/.  This also means that DKMS is going to do
make mrproper in the prepare and clean steps.

* The config file is available in /boot/config-$version-arch.

* /lib/modules/*/source is a dangling symlink to nowhere useful



# dkms add   -m dell_rbu -v 0.8

# dkms build -m dell_rbu -v 0.8 \
  --kernelsourcedir=/usr/src/kernel-source-2.6.8 \
  --config=/boot/config-2.6.8-2-686

# dkms install -m dell_rbu -v 0.8


worked for me on a Sarge i686 install.


TODO:
- figure out what mkdeb (akin to mkrpm) would look like



Packages at http://linux.dell.com/dkms/debian/

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com  www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com


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