Ubuntu Wiki

   1 [19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/11/%23ubuntu-classroom.html following the conclusion of the session.
   2 [19:01] <directhex> righty then. thanks to seb128 for his session there.
   3 [19:01] <directhex> I'd like to apologise in advance if I appear to become unresponsive during this, as if my internet connection has dropped. it'll be because my internet connection has dropped. yay, adsl, etc.
   4 [19:02] <directhex> my intention is to spend a few minutes first discussing mono and how it relates to ubuntu, in packaging terms. then ill go through a couple of example packages (sparkleshare, docky and keepass2 are my example packages, try to ensure you have the source packages and build-deps available if you want to follow along)
   5 [19:02] <directhex> then end with a Q&A session
   6 [19:03] <directhex> so. first things first. mono's a framework for developing apps in the same format as microsoft.net. same bytecode format, same class libraries, etc. this is possible because the bytecode and basic class libraries are an ISO standard that anyone can read through
   7 [19:04] <directhex> mono packages have been available in ubuntu since forever. mono apps have been in the default ubuntu install for about five years - tomboy pretty much every time, and varyingly since then f-spot, gbrainy, and banshee.
   8 [19:05] <directhex> there are about 120 packages in ubuntu which use mono in one form or another - about 40-50 applications, written in c#, and the rest are usually libraries (or C-based libraries offering a Mono interface, such as libubuntuone)
   9 [19:06] <directhex> i'm one of the mono packagers in debian, and i also carry some responsibility for it in ubuntu - we try as far as humanely possible to do mono-related work in debian, then let that work trickle down into ubuntu, minimizing duplicated wotk
  10 [19:06] <directhex> i also wrote the first version of the banshee plugin to access the ubuntu one music store (this has since been adopted by canonical developers)
  11 [19:07] <directhex> why mono? because c# is a very easy language to develop with, whilst still reasonably performant - and it's also pretty lightweight compared to some of the competition. this makes it well positioned to offer an alternative to C, Python, Java, etc
  12 [19:08] <directhex> and you'd be hard pressed to tell the difference between a Mono app written in C#, and a Python or C app, if nobody told you - when an app uses the GTK# framework for designing a GUI, it feels entirely "native", despite the app technically being a .exe file
  13 [19:09] <directhex> note that mono (and .net) .exe files aren't windows (or wine) .exe files. microsoft just weren't bright enough to use a different file type when they wrote the standard. go figure.
  14 [19:09] <directhex> hopefully people have already downloaded some or all of the example apps i mentioned on the UDW wiki - three apps you may or may not have heard off called docky, sparkleshare, and keepass2
  15 [19:10] <directhex> i think sparkleshare is in oneiric but not natty - don't worry about that one if you're not in oneiric
  16 [19:10] <directhex> if you don't have them, remember you use "apt-get source packagename" to download and extract a source package to the current folder
  17 [19:11] <directhex> and "apt-get build-dep packagename" to install the packages you need in order to compile that package
  18 [19:11] <directhex> if you don't want to use a local install, let me grab a web link for the source packages
  19 [19:12] <directhex> http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/sparkleshare.git;a=tree
  20 [19:12] <directhex> http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/docky.git;a=tree
  21 [19:12] <directhex> http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/keepass2.git;a=tree
  22 [19:13] <directhex> there's the browsable sources for the three packages we're using, if you prefer a web browser
  23 [19:14] <directhex> so, let's start things off by looking at docky. docky is an app providing a macos-style dock, for launching applications. it's a c# app, which began life as part of the gnome-do launcher, before being spun off as an independent project
  24 [19:14] <directhex> as with any package, the structure is the same. the upstream source tarball, with an added "debian/" folder containing all the packaging metadata. take a look in debian/
  25 [19:15] <directhex> there are all the simple basic files in here. "compat" specifies the compatibility version which the debhelper package should use for package building commands (we use debhelper 7 extensively in the mono team)
  26 [19:16] <directhex> watch is used for automatically scanning remote servers for package updates. the package maintainer gets an email when the watch file reports on new things. the "uscan" command uses the watch file - e.g. "uscan --report-status" tells me that "Newest version on remote site is 2.1.3, local version is 2.1.2"
  27 [19:16] <directhex> so i guess i've got some work to do. or delegate to someone else, anyway.
  28 [19:17] <directhex> copyright is what it sounds like. the changelog is what it sounds like, requiring standard debian packaging format changelogs. the dch command lets you edit changelogs (e.g. dch -i adds a new changelog entry)
  29 [19:18] <directhex> the source/ folder contains a single file, format, which specifies the debian source format used by the package. we use "3.0 (quilt)" here, which automatically handles the content of the patches/ folder
  30 [19:19] <directhex> and on a related note, patches/ contains changes to the upstream source which are required for the package to work (or make it work better). we have one minor fix, which ricotz probably rolled into 2.1.3, but we don't have her in 2.1.2
  31 [19:19] <directhex> this leaves the two most important files in a debian source package: control and rules.
  32 [19:20] <directhex> control contains the package descriptions, including the dependencies and build-dependencies of the package. docky has quite a lot of build-dependeicies, as it uses a lot of gnome technologies.
  33 [19:21] <directhex> if you look at the package dependencies section, around line 36, you'll see we only have on real dependency, on librsvg2-common
  34 [19:21] <directhex> the rest are "substvars", i.e. when the package is compiled, they will be filled in with real values
  35 [19:22] <directhex> so ${cli:Depends} is filled in by the dh_clideps command, which is executed during package compilation
  36 [19:23] <directhex> which brings me to the final file, rules. debian/rules is a Makefile, which is called by the build commands run on the build servers, in order to build a package
  37 [19:24] <directhex> we use the debhelper 7 format, which allows us to skip the "boring" parts of the file (these boring parts are automatically filled in by the "dh $@" lines at the bottom
  38 [19:24] <directhex> we only do three things here which are any different from a C or C++ app using normal ./confgure and make
  39 [19:25] <directhex> first, we have a line "include /usr/share/cli-common/cli.make" - this tells debhelper to read in the file /usr/share/cli-common/cli.make, which tells it to make changes to the normal sequence of events, and insert some extra ones, such as dh_clideps which builds dependencies on Mono libraries
  40 [19:26] <directhex> look at /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm to see how that happens
  41 [19:27] <directhex> second, we override the "dh_auto_configure" command, and substitute our own version. our version adds an extra variable, redefining MCS. in this package, MCS is the C# compiler program's path. we override this, so we can easily change the c# compiler used (mono-csc is a symbolic link to the distro default compiler)
  42 [19:28] <directhex> that way, if ./configure is searching for "gmcs" or "csc", it accepts our new truth and uses mono-csc instead.
  43 [19:29] <directhex> third, we override dh_makeclilibs, the command which mono library packages use to say "i am a library, packages using me need to do XYZ", and tell it to exclude the usr/lib/docky folder. this is because docky isn't a library, and we don't want its own internal files being treated as distriwide libraries.
  44 [19:29] <directhex> so, that's the whole package. if you run dpkg-buildpackage in there, it'll make a fresh .deb
  45 [19:30] <directhex> if you have the sparkleshare source package, you'll see it looks exactly like docky - simple debhelper 7 format, using ${cli:Depends} for dependencies, etc. simple mono apps.
  46 [19:30] <directhex> now, the last example is a complicated example. keepass2.
  47 [19:31] <directhex> this is originally a Windows app - but its developers wrote it in such a way that it also works on Mac OS X and on Linux, via Mono. bug because it's a Windows app, its developers don't have linuxy things like ./confgure and make - instead, it uses Visual Studio.NET project files, and needs some manual cleaning up
  48 [19:32] <directhex> if you look in the debian/patches folder for keepass2, you'll see a LOT of patches, doing various things - little tweaks here and there to make it behave better on Ubuntu
  49 [19:33] <directhex> the debian/rules file is also much more complicated, as many steps usually handled by an automake makefile are done manually - e.g. putting an executable in /usr/bin or icons in the right places
  50 [19:33] <directhex> rather than "make", we use "xbuild", which is a command to compile Visual Studio.NET project and solution files
  51 [19:34] <directhex> we have a "install" file in debian/, which lists the files produced by the compilation, and where they should be installed to inside the package
  52 [19:35] <directhex> since there's no "make install" to do it for us, it's done semi-manually via these files
  53 [19:36] <directhex> the end result is a package whose contents are laid out in a "native" way - however, because keepass2 uses the System.Windows.Forms GUI toolkit rather than GTK#, it looks a bit pooey.
  54 [19:36] <directhex> i guess that's the packaging walkthrough done. if you're in here, then you probably aren't ready to do a library package (those are more complicated to do)
  55 [19:37] <directhex> and generally speaking, the right place to come and offer assistance is #debian-cli on OFTC, where we do packaging related discussion, including for ubuntu
  56 [19:37] <directhex> now i'm going to open up the Q&A. bear with me whilst i try and wrangle classbot
  57 [19:38] <ClassBot> sera asked: Which version of Mono will be available in Oneiric?
  58 [19:38] <directhex> Oneiric will ship with Mono 2.10.1.
  59 [19:39] <directhex> we're also taking the opportunity to rebuild the entire world using the 4.0 class library (.NET 4.0), replacing the 2.0 class library (.NET 2.0 -> 3.5) that's served us for the last few years
  60 [19:39] <directhex> we always have only one "supported" runtime in releases, because otherwise the package dependency chain for high-level apps like banshee bloats up
  61 [19:40] <directhex> once the transition is over, only 4.0 libraries will be installed by default, not a mix of 2.0 and 4.0 - and older apps are simply rebuilt for 4.0 (we even have old 1.0 apps that we;ve been rebuilding as 2.0 for a while)
  62 [19:40] <directhex> .net generally has major class library versions - they avoid changing (and breaking) it, unless there's a real breaking change. they've only broken it twice so far - 2.0 and 4.0
  63 [19:41] <directhex> monodevelop will also default to 4.0 for new projects, in oneiric (barring an annoying bug i haven't found, which means the first time you run it, it defaults to 2.0). existing projects will cease to compile, unless you change the target framework version to 4.0, as the libraries you use like gtk# will also be 4.0-only
  64 [19:41] <directhex> monodevelop 2.6 beta 3 is already in oneiric
  65 [19:42] <directhex> okay, next
  66 [19:42] <ClassBot> dell asked: please can you give the package name. I did not find it in UDW page
  67 [19:43] <directhex> "docky", "sparkleshare" and "keepass2". sparkleshare is oneiric-only, don't worry about it if you're not on oneiric (or debian, i guess). keepass2 is in natty-backports, if memory serves.
  68 [19:43] <ClassBot> bullgard4 asked: The Ubuntu programm is called KeePassX. Why do you call it »keepass2«?
  69 [19:44] <directhex> KeePassX is a Qt (i think?) reimplementation of the original Keepass 1. Keepass 2 in Ubuntu is the "real" keepass2, as found on Windows, which is a .NET app. the packaging for this is done by jtaylor.
  70 [19:44] <directhex> users are free to use their preferred app - i believe keepass2 has more features than keepassx, but looks kinda bad due to being a SWF app
  71 [19:44] <ClassBot> bullgard4 asked: What does mean the phrase »for the greater good« in the headline: "Packaging Mono for the greater good"?
  72 [19:45] <directhex> there are a few mono apps out there on the web, with home-grown packaging (i.e. which don't follow the packaging best practices from this talk). those packages tend to suffer somewhat as a result. the universe will be just that little bit better if more mono apps are packaged *well*
  73 [19:46] <ClassBot> matteonardi asked: do you know if MonoDevelop is "good enough" for auto-generating autotools setups for simple projects? (I'm developing a simple checkers game with mono.. and after taking a look at autotools, I'd rather avoid them if possible!)
  74 [19:47] <directhex> honestly, I don't know. i haven't used the autofoo integration much. from a packaging perspective, i know sources produced this way have some issues, which we need to patch in the packages.
  75 [19:48] <directhex> given the maturity of xbuild, and that MD uses VS.NET project format as its own data format, i'd be inclined to use that - it also invites contributions from windows-based developers, since the same source can be compiled on windows easily, in vs.net or monodevelop or sharpdevelop, without needing cygwin or mingw
  76 [19:48] <directhex> when i started using mono, we had neither autofoo integration nor xbuild. it was all manual. and all this was green fields ;)
  77 [19:48] <ClassBot> bullgard4 asked: '/usr/local/src$ sudo apt-getsource keepassx; gpgv: Unterschrift kann nicht geprüft werden. Öffentlicher Schlüssel nicht gefunden.' Why can apt-get source not find the public key?
  78 [19:49] <directhex> "apt-get source" uses your personal gpg keyring for verifying downloads. if you don't have the key in question in your personal keyring, then it'll throw an error. you can use "gpg --recv-key ABCDABCD" for the key id in question, to download & add it
  79 [19:50] <ClassBot> bullgard4 asked: Why did you write the 1st version of the Banshee plugin to access the Ubuntu One music store in Mono and not in Python?
  80 [19:50] <directhex> because banshee is a mono app - it made sense to make a mono app plugin in c#
  81 [19:50] <ClassBot> There are 10 minutes remaining in the current session.
  82 [19:51] <directhex> as it happens, most of the heavy lifting in that plugin is done by libubuntuone, which is a C library - but it offers a C# binding (i might have done that too, i don't remember). the only parts written in c# are linking the gtk+ events into banshee, and handling the library adding for downloading tracks
  83 [19:52] <ClassBot> coalitians asked: I ram dpkg --build docky-2.1.2 but i get this error
  84 [19:52] <directhex> <coalitians> dpkg-deb: error: failed to open package info file `docky-2.1.2/DEBIAN/control' for reading: No such file or directory
  85 [19:52] <directhex> try dpkg-buildpackage. "dpkg --build" does something subtly different
  86 [19:53] <ClassBot> sera asked: Are the difficulties in packaging Mono over? i.e. will we get Mono 2.12 in 12.04?
  87 [19:53] <directhex> I can't make promises given 2.12 doesn't exist yet... i can say that uploads involving a transition (e.g. this 4.0 transition which is currently ongoing and about half complete) take MUCH longer than those without
  88 [19:54] <directhex> mono's source package builds over a hundred binary packages - that's a lot of manual checking to do
  89 [19:54] <directhex> there's also the time taken to make mono build on multiple architectures, update our ports (e.g. kfreebsd-amd64 in debian), and so on. it takes time
  90 [19:55] <directhex> we have a new workflow which should allow for faster, more frequent uploads of new mono releases, but it's still largely dependent upon one person, who does this work in his spare time (and therefore it isn't reasonable to *demand* things from him).
  91 [19:55] <ClassBot> There are 5 minutes remaining in the current session.
  92 [19:56] <directhex> in my experience, a visit to the team's donations page (http://wiki.debian.org/Teams/DebianMonoGroup/DonationRegistry) and a donation to Mirco Bauer are an excellent way to get updates to Mono itself. although i think 2.10.1 is pretty final for oneiric (no 2.10.2, not worth it at this point)
  93 [19:56] <ClassBot> bullgard4 asked: What IRC channel do you frequent? I am asking for the case that I have additional questions after having studied in full your lession.
  94 [19:57] <directhex> #debian-cli on irc.oftc.net is the best bet. that's where mono-related things happen.
  95 [19:57] <directhex> !q
  96 [19:57] <directhex> bah. anyway, no questions in the queue?
  97 [19:57] <directhex> 3 minutes remaining. ask anything
  98 [19:58] <ClassBot> rww asked: What's your favorite colour?
  99 [19:58] <directhex> bloo!
 100 [19:58] <ClassBot> john_g asked: Maybe I missed this. What does cli mean in this context?
 101 [19:59] <directhex> Common Language Infrastructure. it's a term used in the .NET standards documentation, without the trademark associations of "microsoft .net"
 102 [19:59] <ClassBot> grungekid_ asked: What are the advantages of using mono over other languages such as python? Why do you choose to use it?
 103 [20:00] <directhex> i personally deeply dislike python syntax - and c# tends to perform MUCH faster than python. it's good if you have a java background, syntacically
 104 [20:00] <directhex> and i'm out of time. i'll finish questions in #ubuntu-classroom-chat
 105 [20:00] <directhex> next up is... barry i think?
 106 [19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/11/%23ubuntu-classroom.html following the conclusion of the session.
 107 [19:01] <directhex> righty then. thanks to seb128 for his session there.
 108 [19:01] <directhex> I'd like to apologise in advance if I appear to become unresponsive during this, as if my internet connection has dropped. it'll be because my internet connection has dropped. yay, adsl, etc.
 109 [19:02] <directhex> my intention is to spend a few minutes first discussing mono and how it relates to ubuntu, in packaging terms. then ill go through a couple of example packages (sparkleshare, docky and keepass2 are my example packages, try to ensure you have the source packages and build-deps available if you want to follow along)
 110 [19:02] <directhex> then end with a Q&A session
 111 [19:03] <directhex> so. first things first. mono's a framework for developing apps in the same format as microsoft.net. same bytecode format, same class libraries, etc. this is possible because the bytecode and basic class libraries are an ISO standard that anyone can read through
 112 [19:04] <directhex> mono packages have been available in ubuntu since forever. mono apps have been in the default ubuntu install for about five years - tomboy pretty much every time, and varyingly since then f-spot, gbrainy, and banshee.
 113 [19:05] <directhex> there are about 120 packages in ubuntu which use mono in one form or another - about 40-50 applications, written in c#, and the rest are usually libraries (or C-based libraries offering a Mono interface, such as libubuntuone)
 114 [19:06] <directhex> i'm one of the mono packagers in debian, and i also carry some responsibility for it in ubuntu - we try as far as humanely possible to do mono-related work in debian, then let that work trickle down into ubuntu, minimizing duplicated wotk
 115 [19:06] <directhex> i also wrote the first version of the banshee plugin to access the ubuntu one music store (this has since been adopted by canonical developers)
 116 [19:07] <directhex> why mono? because c# is a very easy language to develop with, whilst still reasonably performant - and it's also pretty lightweight compared to some of the competition. this makes it well positioned to offer an alternative to C, Python, Java, etc
 117 [19:08] <directhex> and you'd be hard pressed to tell the difference between a Mono app written in C#, and a Python or C app, if nobody told you - when an app uses the GTK# framework for designing a GUI, it feels entirely "native", despite the app technically being a .exe file
 118 [19:09] <directhex> note that mono (and .net) .exe files aren't windows (or wine) .exe files. microsoft just weren't bright enough to use a different file type when they wrote the standard. go figure.
 119 [19:09] <directhex> hopefully people have already downloaded some or all of the example apps i mentioned on the UDW wiki - three apps you may or may not have heard off called docky, sparkleshare, and keepass2
 120 [19:10] <directhex> i think sparkleshare is in oneiric but not natty - don't worry about that one if you're not in oneiric
 121 [19:10] <directhex> if you don't have them, remember you use "apt-get source packagename" to download and extract a source package to the current folder
 122 [19:11] <directhex> and "apt-get build-dep packagename" to install the packages you need in order to compile that package
 123 [19:11] <directhex> if you don't want to use a local install, let me grab a web link for the source packages
 124 [19:12] <directhex> http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/sparkleshare.git;a=tree
 125 [19:12] <directhex> http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/docky.git;a=tree
 126 [19:12] <directhex> http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/keepass2.git;a=tree
 127 [19:13] <directhex> there's the browsable sources for the three packages we're using, if you prefer a web browser
 128 [19:14] <directhex> so, let's start things off by looking at docky. docky is an app providing a macos-style dock, for launching applications. it's a c# app, which began life as part of the gnome-do launcher, before being spun off as an independent project
 129 [19:14] <directhex> as with any package, the structure is the same. the upstream source tarball, with an added "debian/" folder containing all the packaging metadata. take a look in debian/
 130 [19:15] <directhex> there are all the simple basic files in here. "compat" specifies the compatibility version which the debhelper package should use for package building commands (we use debhelper 7 extensively in the mono team)
 131 [19:16] <directhex> watch is used for automatically scanning remote servers for package updates. the package maintainer gets an email when the watch file reports on new things. the "uscan" command uses the watch file - e.g. "uscan --report-status" tells me that "Newest version on remote site is 2.1.3, local version is 2.1.2"
 132 [19:16] <directhex> so i guess i've got some work to do. or delegate to someone else, anyway.
 133 [19:17] <directhex> copyright is what it sounds like. the changelog is what it sounds like, requiring standard debian packaging format changelogs. the dch command lets you edit changelogs (e.g. dch -i adds a new changelog entry)
 134 [19:18] <directhex> the source/ folder contains a single file, format, which specifies the debian source format used by the package. we use "3.0 (quilt)" here, which automatically handles the content of the patches/ folder
 135 [19:19] <directhex> and on a related note, patches/ contains changes to the upstream source which are required for the package to work (or make it work better). we have one minor fix, which ricotz probably rolled into 2.1.3, but we don't have her in 2.1.2
 136 [19:19] <directhex> this leaves the two most important files in a debian source package: control and rules.
 137 [19:20] <directhex> control contains the package descriptions, including the dependencies and build-dependencies of the package. docky has quite a lot of build-dependeicies, as it uses a lot of gnome technologies.
 138 [19:21] <directhex> if you look at the package dependencies section, around line 36, you'll see we only have on real dependency, on librsvg2-common
 139 [19:21] <directhex> the rest are "substvars", i.e. when the package is compiled, they will be filled in with real values
 140 [19:22] <directhex> so ${cli:Depends} is filled in by the dh_clideps command, which is executed during package compilation
 141 [19:23] <directhex> which brings me to the final file, rules. debian/rules is a Makefile, which is called by the build commands run on the build servers, in order to build a package
 142 [19:24] <directhex> we use the debhelper 7 format, which allows us to skip the "boring" parts of the file (these boring parts are automatically filled in by the "dh $@" lines at the bottom
 143 [19:24] <directhex> we only do three things here which are any different from a C or C++ app using normal ./confgure and make
 144 [19:25] <directhex> first, we have a line "include /usr/share/cli-common/cli.make" - this tells debhelper to read in the file /usr/share/cli-common/cli.make, which tells it to make changes to the normal sequence of events, and insert some extra ones, such as dh_clideps which builds dependencies on Mono libraries
 145 [19:26] <directhex> look at /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm to see how that happens
 146 [19:27] <directhex> second, we override the "dh_auto_configure" command, and substitute our own version. our version adds an extra variable, redefining MCS. in this package, MCS is the C# compiler program's path. we override this, so we can easily change the c# compiler used (mono-csc is a symbolic link to the distro default compiler)
 147 [19:28] <directhex> that way, if ./configure is searching for "gmcs" or "csc", it accepts our new truth and uses mono-csc instead.
 148 [19:29] <directhex> third, we override dh_makeclilibs, the command which mono library packages use to say "i am a library, packages using me need to do XYZ", and tell it to exclude the usr/lib/docky folder. this is because docky isn't a library, and we don't want its own internal files being treated as distriwide libraries.
 149 [19:29] <directhex> so, that's the whole package. if you run dpkg-buildpackage in there, it'll make a fresh .deb
 150 [19:30] <directhex> if you have the sparkleshare source package, you'll see it looks exactly like docky - simple debhelper 7 format, using ${cli:Depends} for dependencies, etc. simple mono apps.
 151 [19:30] <directhex> now, the last example is a complicated example. keepass2.
 152 [19:31] <directhex> this is originally a Windows app - but its developers wrote it in such a way that it also works on Mac OS X and on Linux, via Mono. bug because it's a Windows app, its developers don't have linuxy things like ./confgure and make - instead, it uses Visual Studio.NET project files, and needs some manual cleaning up
 153 [19:32] <directhex> if you look in the debian/patches folder for keepass2, you'll see a LOT of patches, doing various things - little tweaks here and there to make it behave better on Ubuntu
 154 [19:33] <directhex> the debian/rules file is also much more complicated, as many steps usually handled by an automake makefile are done manually - e.g. putting an executable in /usr/bin or icons in the right places
 155 [19:33] <directhex> rather than "make", we use "xbuild", which is a command to compile Visual Studio.NET project and solution files
 156 [19:34] <directhex> we have a "install" file in debian/, which lists the files produced by the compilation, and where they should be installed to inside the package
 157 [19:35] <directhex> since there's no "make install" to do it for us, it's done semi-manually via these files
 158 [19:36] <directhex> the end result is a package whose contents are laid out in a "native" way - however, because keepass2 uses the System.Windows.Forms GUI toolkit rather than GTK#, it looks a bit pooey.
 159 [19:36] <directhex> i guess that's the packaging walkthrough done. if you're in here, then you probably aren't ready to do a library package (those are more complicated to do)
 160 [19:37] <directhex> and generally speaking, the right place to come and offer assistance is #debian-cli on OFTC, where we do packaging related discussion, including for ubuntu
 161 [19:37] <directhex> now i'm going to open up the Q&A. bear with me whilst i try and wrangle classbot
 162 [19:38] <ClassBot> sera asked: Which version of Mono will be available in Oneiric?
 163 [19:38] <directhex> Oneiric will ship with Mono 2.10.1.
 164 [19:39] <directhex> we're also taking the opportunity to rebuild the entire world using the 4.0 class library (.NET 4.0), replacing the 2.0 class library (.NET 2.0 -> 3.5) that's served us for the last few years
 165 [19:39] <directhex> we always have only one "supported" runtime in releases, because otherwise the package dependency chain for high-level apps like banshee bloats up
 166 [19:40] <directhex> once the transition is over, only 4.0 libraries will be installed by default, not a mix of 2.0 and 4.0 - and older apps are simply rebuilt for 4.0 (we even have old 1.0 apps that we;ve been rebuilding as 2.0 for a while)
 167 [19:40] <directhex> .net generally has major class library versions - they avoid changing (and breaking) it, unless there's a real breaking change. they've only broken it twice so far - 2.0 and 4.0
 168 [19:41] <directhex> monodevelop will also default to 4.0 for new projects, in oneiric (barring an annoying bug i haven't found, which means the first time you run it, it defaults to 2.0). existing projects will cease to compile, unless you change the target framework version to 4.0, as the libraries you use like gtk# will also be 4.0-only
 169 [19:41] <directhex> monodevelop 2.6 beta 3 is already in oneiric
 170 [19:42] <directhex> okay, next
 171 [19:42] <ClassBot> dell asked: please can you give the package name. I did not find it in UDW page
 172 [19:43] <directhex> "docky", "sparkleshare" and "keepass2". sparkleshare is oneiric-only, don't worry about it if you're not on oneiric (or debian, i guess). keepass2 is in natty-backports, if memory serves.
 173 [19:43] <ClassBot> bullgard4 asked: The Ubuntu programm is called KeePassX. Why do you call it »keepass2«?
 174 [19:44] <directhex> KeePassX is a Qt (i think?) reimplementation of the original Keepass 1. Keepass 2 in Ubuntu is the "real" keepass2, as found on Windows, which is a .NET app. the packaging for this is done by jtaylor.
 175 [19:44] <directhex> users are free to use their preferred app - i believe keepass2 has more features than keepassx, but looks kinda bad due to being a SWF app
 176 [19:44] <ClassBot> bullgard4 asked: What does mean the phrase »for the greater good« in the headline: "Packaging Mono for the greater good"?
 177 [19:45] <directhex> there are a few mono apps out there on the web, with home-grown packaging (i.e. which don't follow the packaging best practices from this talk). those packages tend to suffer somewhat as a result. the universe will be just that little bit better if more mono apps are packaged *well*
 178 [19:46] <ClassBot> matteonardi asked: do you know if MonoDevelop is "good enough" for auto-generating autotools setups for simple projects? (I'm developing a simple checkers game with mono.. and after taking a look at autotools, I'd rather avoid them if possible!)
 179 [19:47] <directhex> honestly, I don't know. i haven't used the autofoo integration much. from a packaging perspective, i know sources produced this way have some issues, which we need to patch in the packages.
 180 [19:48] <directhex> given the maturity of xbuild, and that MD uses VS.NET project format as its own data format, i'd be inclined to use that - it also invites contributions from windows-based developers, since the same source can be compiled on windows easily, in vs.net or monodevelop or sharpdevelop, without needing cygwin or mingw
 181 [19:48] <directhex> when i started using mono, we had neither autofoo integration nor xbuild. it was all manual. and all this was green fields ;)
 182 [19:48] <ClassBot> bullgard4 asked: '/usr/local/src$ sudo apt-getsource keepassx; gpgv: Unterschrift kann nicht geprüft werden. Öffentlicher Schlüssel nicht gefunden.' Why can apt-get source not find the public key?
 183 [19:49] <directhex> "apt-get source" uses your personal gpg keyring for verifying downloads. if you don't have the key in question in your personal keyring, then it'll throw an error. you can use "gpg --recv-key ABCDABCD" for the key id in question, to download & add it
 184 [19:50] <ClassBot> bullgard4 asked: Why did you write the 1st version of the Banshee plugin to access the Ubuntu One music store in Mono and not in Python?
 185 [19:50] <directhex> because banshee is a mono app - it made sense to make a mono app plugin in c#
 186 [19:51] <directhex> as it happens, most of the heavy lifting in that plugin is done by libubuntuone, which is a C library - but it offers a C# binding (i might have done that too, i don't remember). the only parts written in c# are linking the gtk+ events into banshee, and handling the library adding for downloading tracks
 187 [19:52] <ClassBot> coalitians asked: I ram dpkg --build docky-2.1.2 but i get this error
 188 [19:52] <directhex> <coalitians> dpkg-deb: error: failed to open package info file `docky-2.1.2/DEBIAN/control' for reading: No such file or directory
 189 [19:52] <directhex> try dpkg-buildpackage. "dpkg --build" does something subtly different
 190 [19:53] <ClassBot> sera asked: Are the difficulties in packaging Mono over? i.e. will we get Mono 2.12 in 12.04?
 191 [19:53] <directhex> I can't make promises given 2.12 doesn't exist yet... i can say that uploads involving a transition (e.g. this 4.0 transition which is currently ongoing and about half complete) take MUCH longer than those without
 192 [19:54] <directhex> mono's source package builds over a hundred binary packages - that's a lot of manual checking to do
 193 [19:54] <directhex> there's also the time taken to make mono build on multiple architectures, update our ports (e.g. kfreebsd-amd64 in debian), and so on. it takes time
 194 [19:55] <directhex> we have a new workflow which should allow for faster, more frequent uploads of new mono releases, but it's still largely dependent upon one person, who does this work in his spare time (and therefore it isn't reasonable to *demand* things from him).
 195 [19:56] <directhex> in my experience, a visit to the team's donations page (http://wiki.debian.org/Teams/DebianMonoGroup/DonationRegistry) and a donation to Mirco Bauer are an excellent way to get updates to Mono itself. although i think 2.10.1 is pretty final for oneiric (no 2.10.2, not worth it at this point)
 196 [19:56] <ClassBot> bullgard4 asked: What IRC channel do you frequent? I am asking for the case that I have additional questions after having studied in full your lession.
 197 [19:57] <directhex> #debian-cli on irc.oftc.net is the best bet. that's where mono-related things happen.
 198 [19:57] <directhex> !q
 199 [19:57] <directhex> bah. anyway, no questions in the queue?
 200 [19:57] <directhex> 3 minutes remaining. ask anything
 201 [19:58] <ClassBot> rww asked: What's your favorite colour?
 202 [19:58] <directhex> bloo!
 203 [19:58] <ClassBot> john_g asked: Maybe I missed this. What does cli mean in this context?
 204 [19:59] <directhex> Common Language Infrastructure. it's a term used in the .NET standards documentation, without the trademark associations of "microsoft .net"
 205 [19:59] <ClassBot> grungekid_ asked: What are the advantages of using mono over other languages such as python? Why do you choose to use it?
 206 [20:00] <directhex> i personally deeply dislike python syntax - and c# tends to perform MUCH faster than python. it's good if you have a java background, syntacically
 207 [20:00] <directhex> and i'm out of time. i'll finish questions in #ubuntu-classroom-chat
 208 [20:00] <directhex> next up is... barry i think?